Re: SIGPIPE handling

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Manfred Spraul <manfred(at)colorfullife(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: SIGPIPE handling
Date: 2003-11-17 00:27:38
Message-ID: 200311170027.hAH0Rcu27909@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2003-11-17 01:58:48 Re: [PATCHES] SRA Win32 sync() code
Previous Message Bruce Momjian 2003-11-17 00:17:49 Re: SIGPIPE handling