Re: libpq is not thread safe - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: libpq is not thread safe
Date
Msg-id 1241424350.1355.65.camel@localhost
Whole thread Raw
In response to Re: libpq is not thread safe  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: libpq is not thread safe  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Tom Lane píše v ne 03. 05. 2009 v 16:39 -0400:
> Zdenek Kotala <Zdenek.Kotala@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





pgsql-hackers by date:

Previous
From: Laurent Laborde
Date:
Subject: high shared buffer and swap
Next
From: James Pye
Date:
Subject: Re: Python 3.0 does not work with PL/Python