Tom Lane wrote: > Manfred Spraul <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
