Re: libpq and psql not on same page about SIGPIPE

Tom Lane wrote:
> Manfred Spraul <manfred@colorfullife.com> writes:
> > Tom Lane wrote:
> >> Not really: it only solves the problem *if you change the application*,
> >> which is IMHO not acceptable.
> 
> > No. non-threaded apps do not need to change. The default is the old, 7.3 
> > code: change the signal handler around the write calls. Which means that 
> > non-threaded apps are guaranteed to work without any changes, regardless 
> > of the libpq thread safety setting.
> 
> Hmm, so you propose that a thread-enabled library must contain both code
> paths and choose between them on the fly?  That seems like the worst of
> all possible worlds --- it's not backwards compatible, it's therefore
> unsafe, it's slow, *and* it'll be #ifdef hell to read.
> 
> On a platform that has pthread_sigmask, ISTM we can use that
> unconditionally and it'll work whether the calling app is threaded or
> not.  We only fall back to the pqsignal method if we aren't supporting
> threads.  There's no need for a runtime test nor for an API change.

Agreed.  Manfred, I guess the big question is why not use something that
is automatic like I just applied?  

Now that the patch is in, would someone run some threaded performance
tests and see if those pg_*_sigpipe routines are causing any performance
problems.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073