Per http://archives.postgresql.org/pgsql-hackers/2012-10/msg00167.php
On Wed, Oct 3, 2012 at 9:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> To bring that closer to home, suppose you have a program with an open
> database connection in libpq, and you fork(), and then parent and child
> both try to use the connection. How well would that work? Is it the
> fault of fork()?
This brings to mind a lot of issues we see reported among our users:
I see the problem of database connections shared among processes as a
reported problem *all the time*, because of the popularity of
fork-based web servers. If you do something just a tiny bit wrong you
end up establishing the connection before the fork and then two things
can happen:
* If SSL is off, you never notice until you get some really bizarre
issues that result from an unfortunate collision of protocol traffic.
Since many applications have idle-time, this happens rarely enough to
be subtle that some people never take notice. A tell-tell sign is an
error reported from something that looks like one query jammed into
another.
* When SSL is enabled this strangeness is seen more or less
immediately, but shows up as cryptic OpenSSL complaints, to which no
earthly person is going to know what to do.
It would be fantastic for libpq to somehow monitor use of a connection
from multiple PIDs that share a parent and deliver an error indicating
what is wrong. Unfortunately detecting that would require either a
file or some kind of shared memory map, AFAIK, and I don't know how
keen anyone is on accepting that patch. So, may I ask: how keen is
anyone on accepting such a patch, and under what conditions of
mechanism?
As a minor functional downside, it would hurt a hypothetical user that
is carefully sharing a backend file descriptor between processes using
libpq and synchronizing them very carefully (notably, with encryption
this becomes almost comically difficult and brittle). I conjecture
such a person is almost entirely hypothetical in nature.
--
fdr