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