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 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