Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

RTFM. The 4th param to mysql_connect()..

Wow, have you actually read the code you are flaming us about?  mysql_close() does a zend_list_delete() on the connection.  The handler for a list deletion is this function:

static void _close_mysql_link(zend_rsrc_list_entry *rsrc TSRMLS_DC)
{
    php_mysql_conn *link = (php_mysql_conn *)rsrc->ptr;
    void (*handler) (int);

    handler = signal(SIGPIPE, SIG_IGN);
    mysql_close(&link->conn);
    signal(SIGPIPE, handler);
    efree(link);
    MySG(num_links)--;
}

This calls the libmysql mysql_close() function which closes the connection.

I guess what you are referring to is the _close_mysql_plink() function, but that is specifically for dealing with a persistent connection which you have to explicitly define to me persistent by calling mysql_pconnect().  If you want full control over when you open and close your connection you obviously shouldn't open the connection as persistent.  Use the regular mysql_connect() call and you are in control.

Hi-

(sorry if I was a bit harsh, before I really like PHP, but I was very unpleasantly surprised by the behavior I am seeing :-) I did not intend to flame anyone)

Someone (I think sniper@php.net) replied to me that this is not a bug and I should RTFM and pass the 4th param to mysql_connect. I guess I wasn't clear before, but I am passing that parameter in and it does not appear to be creating a new link even though that's what I'm telling it to do, which is why I filed this as a bug. Try it yourself and you will see. The scenario is a lot of nested function calls and functions referenced from other included php files. Sets of php functions grouped into libraries and called by many other pieces of code. Operations performed on multiple DBs. Etc.

I also got a response from someone (rasmus@php.net - are you the rasmus who started PHP? dude I did not mean to flame you, I have really gotten a lot of benefit out of PHP over the years... but I still have questions about this behavior) who said that mysql_close actually DOES close the DB connection. There are multiple comments from multiple users on the php.net wiki user comments that claim that mysql_close actually only decrements the "resource counter" but maybe those comments are no longer valid. I can say that based on the testing I am doing, mysql_close does not seem to be behaving as you describe, although I have not looked at the source. One question I would ask is about this "reference count" - is mysql_close's operation dependent on this count? What happens to the count as functions are called within other functions?

Thanks.

I showed you the exact mysql_close() code.  There is no ref counting anywhere and it explicitly calls the low-level mysql_close() call assuming we are not dealing with a persistent connection.  Don't go by random comments.  Provide a short reproducable test case that shows a real problem and then get back to us.  You haven't provided anything for us to go on.  Your assertion that a mysql_close() on a non-persistent connection doesn't close the connection is obviously false by looking at the code.

Looking through the mysql_connect() code which is not quite as obvious, I suppose there could be a bug, but it really doesn't look like it.  When new_link is set for a non-persistent connection, there is an explicit call to the low-level mysql_init() followed by a mysql_real_connect() call.  If that doesn't open a new connection for you, then you need to file a bug with the MySQL people, because then the bug is in the low-level MySQL client library.

But again, an actual reproducable test-case is required here since there is no obvious problem in the code.