Manfred Spraul wrote: > Tom Lane wrote: > > >Not really: it only solves the problem *if you change the application*, > >which is IMHO not acceptable. In particular, why should a non-threaded > >app expect to have to change to deal with this issue? But we can't > >safely build a thread-safe libpq.so for general use if it breaks > >non-threaded apps that haven't been changed. > > > > > > > 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. > Threaded apps would have to change, but how many threaded apps use > libpq? They check their code anyway - either just add PQinitLib() or > review (and potentialy update) their signal handling code if it match > any of the gotchas of the transparent handling.
So without the call we do the old non-threaded version of the code. Yea, we could do that, but I think the most recent patch is clearer. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
