Magnus Hagander <mag...@hagander.net> writes:
> 2010/1/24 Joe Conway <m...@joeconway.com>:
>> Sorry for being thick -- I'm still missing something. I don't understand
>> why any user program using libpq/PQexec running on Windows does not have
>> the same issue. Or to put it another way, why does this only apply to
>> libpq calls from backend modules?
> Because Windows programs in general don't rely on working Unix signal
> semantics - since Win32 doesn't *have* them.
The real question is why is it so critical for our emulated signals to
be able to interrupt these operations.
If you're trying to tell me that Hot Standby is too fragile to work
unless it can interrupt them, then HS has got a serious problem, and
it is not libpq's fault. There is an enormous amount of code in the
backend that can run for long periods of time without noticing signals,
and not all of that is fixable. Consider for example a plperl,
plpython, or pltcl function that goes off and does a long computation.
So I'm thinking that proposing to kluge up libpq in this area isn't
solving the real problem anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
