Re: libpq and psql not on same page about SIGPIPE

Manfred Spraul wrote:
> Bruce Momjian wrote:
> 
> >Comments?  This seems like our only solution.
> >
> >  
> >
> This would be a transparent solution. Another approach would be:
> - Use the old 7.3 approach by default. This means perfect backward 
> compatibility for single-threaded apps and broken multithreaded apps.
> - Add a new PQinitDB(int disableSigpipeHandler) initialization function. 
> Document that multithreaded apps must call the function with 
> disableSigpipeHandle=1 and handle SIGPIPE for libpq. Perhaps with a 
> reference implementation in libpq (i.e. a sigpipeMode with 0 for old 
> approach, 1 for do nothing, 2 for install our own handler).
> 
> It would prefer that approach:
> It means that the multithreaded libpq apps must be updated [are there 
> any?], but the solution is simpler and less fragile than calling 4 
> signal handling function in a row to selectively block SIGPIPE per-thread.

I think we can get away with three function calls because we can check
errno for EPIPE from the send() call.  We already have two function
calls in there so I don't see a third as a huge problem and not worth an
API change unless someone tells us it is a performance hit.

One thing I know from the broken 7.4 code is that calling signal() from
inside a thread is very slow on Linux, like a 20% performance hit
because I assume it has to adjust all the threads signal stacks or
something.  Anyway, I assume thread_sigmask() and sigpending() are not
huge hits.

In fact, by checking EPIPE from send() we don't need sigpending at all.
We just block and (if EPIPE) clear using sigwait(), then unblock.  I
think we can document that if you are blocking SIGPIPE in your
application and wait to handle it later, you can't keep the pending
signal through a libpq call.  I think that is a much easier requirement
than adding a new API call.  The most common case of SIG_IGN/SIG_DFL is
not affected by this, only cases where they define their own signal
handler, block it, and then trying to keep a call active across a libpq
call.

Manfred, glad you are around to discuss this.  After much research I
came up with a method and then found your description that matched it so
I felt I was on the right track.

--  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