Re: libpq is not thread safe

Zdenek Kotala wrote:
>
> Tom Lane p??e v ne 03. 05. 2009 v 16:39 -0400:
> > Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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.

Done, patch attached and applied.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +