Re: libpq and psql not on same page about SIGPIPE

Tom Lane wrote:
> Manfred Spraul <manfred(at)colorfullife(dot)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(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