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