Tom Lane píše v ne 03. 05. 2009 v 16:39 -0400:
> Zdenek Kotala <zdenek.kot...@sun.com> writes:
> > When postgreSQL is compiled with --thread-safe that libpq should be
> > thread safe. But it is not true when somebody call fork(). The problem
> > is that fork() forks only active threads and some mutex can stay locked
> > by another thread. We use ssl_config mutex which is global.
>
> fork() without exec() when there are open libpq connections is
> unbelievably dangerous anyway --- you will have multiple processes
> that all think they own the same database connection.
The difference is that developer can close connection, but he is not
able to unlock a lock after fork. OK libpq does not offer any PQFinish
variant which frees only resources and close connection without
terminate message, but he can do it with dirty hacking.
Another advantage of atfork handler is that you can close all open
connection and clean resource (similar to what pkcs11 library does). But
at this moment libpq does not keep list of open connections and atfork
handler works only with pthreads.
> I think writing code to deal with this for the ssl_config mutex is entirely a
> waste
> of time.
yeah, I prefer to document it together how to deal with fork() and
sessions.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
