Re: SIGPIPE handling - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: SIGPIPE handling
Date
Msg-id 200311170027.hAH0Rcu27909@candle.pha.pa.us
Whole thread Raw
In response to Re: SIGPIPE handling  (Manfred Spraul <manfred@colorfullife.com>)
Responses Re: SIGPIPE handling  (Manfred Spraul <manfred@colorfullife.com>)
List pgsql-patches
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >I thought it should be global too, basically testing on the first
> >connection request.
> >
> What if two PQconnect calls happen at the same time?
> I would really prefer the manual approach with a new PQsetsighandler
> function - the autodetection is fragile, it's trivial to find a special
> case where it breaks.
> Bruce, you wrote that a new function would be overdesign. Are you sure?
> Your simpler proposals all fail with multithreaded apps.
> I've attached the patch that implements the global flag with two special
> function that access it.

Here is my logic --- 99% of apps don't install a SIGPIPE signal handler,
and 90% will not add a SIGPIPE/SIG_IGN call to their applications.  I
guess I am looking for something that would allow the performance
benefit of not doing a pgsignal() call around very send() for the
majority of our apps.  What was the speed improvement?

Just the fact you had to add the SIG_IGN call to pgbench shows that most
apps need some special handling to get this performance benefit, and I
would like to avoid that.

Your PQsetsighandler() idea --- would that be fore SIGPIPE only?  Would
it be acceptable to tell application developers they have to use
PQsetsig*pipe*handler() call to register a SIGPIPE handler?  If so, that
would be great because we would do the pgsignal call around send() only
when it was needed.  It might be the cleanest way and the most reliable.

Granted, we need to do something because our current setup isn't even
thread-safe.  Also, how is your patch more thread-safe than the old one?
The detection is thread-safe, but I don't see how the use is.  If you
still pgsignal around the calls, I don't see how two threads couldn't
do:

    thread 1            thread 2
    --------            --------
    pgsignal(SIGPIPE, SIG_IGN);
                    pgsignal(SIGPIPE, SIG_DFL);
                    send();
                    pgsignal(SIGPIPE, SIG_DFL);

    send();
    pgsignal(SIGPIPE, SIG_DFL);

This runs thread1 with SIGPIPE as SIG_DFL.

What are we ignoring the SIGPIPE for on send anyway?  Is this in case
the backend crashed?

--
  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, Pennsylvania 19073

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: SIGPIPE handling
Next
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] SRA Win32 sync() code