Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> 2010/1/24 Joe Conway <mail@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.
The process won't react to a shutdown request otherwise, while it's
waiting for the response to PQexec(). It's not such a big deal for
walreceiver, actually, because it already uses select() (with emulation)
in the main loop, but it's theoretically possible for the connection to
be silently lost during the initial handshake, after sending the Query
message, before receiving a response.
dblink/contrib has the same issue, it might wait for a response forever.
Hmm, maybe we should just TCP_KEEPALIVE (if available) on the
connection. We should really be doing that in walreceiver anyway,
walreceiver won't otherwise notice if the connection is silently lost,
and won't know to reconnect.
> 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.
No, it's not related to Hot Standby.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com