Per http://archives.postgresql.org/pgsql-hackers/2012-10/msg00167.php
On Wed, Oct 3, 2012 at 9:41 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers