Re: libpq WSACleanup is not needed
От | Bruce Momjian |
---|---|
Тема | Re: libpq WSACleanup is not needed |
Дата | |
Msg-id | 200901191920.n0JJKIE17857@momjian.us обсуждение исходный текст |
Ответ на | Re: libpq WSACleanup is not needed (James Mansion <james@mansionfamily.plus.com>) |
Ответы |
Re: libpq WSACleanup is not needed
|
Список | pgsql-hackers |
James Mansion wrote: > Magnus Hagander wrote: > > The use-case of rapidly creating and dropping connections isn't > > particularly common, I think. And there is a perfectly functioning > > workaround - something that we should perhaps document in the FAQ or > > somewhere in the documentation? > > > Would it be accetable to do initialise if the number of connections > is changing from 0, and tidy if the cumber goes back to 0? > Applications that retain a connection would not suffer the cost > on subsequent connect/disconnect. Yes, we do that now to clear the SSL callbacks in libpq (see variable 'ssl_open_connections'): CRYPTO_set_locking_callback(NULL); CRYPTO_set_id_callback(NULL); If we don't remove them when going to zero connections then unloading libpq can cause PHP to crash because it thinks the callback functions are still loaded. We could have gone with a more elegant init/uninit solution but there is a history of slow upstream adoption of libpq API changes. In this case I am thinking WSACleanup() should probably follow the same pattern. Having load/unload is superior, but if adoption of that API is <10%, you will probably get the most advantage for the most users in making it automatic. The one big difference with SSL is that the SSL callback unload calls where cheap, while WSACleanup() is expensive. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: