Re: Streaming Replication on win32 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Streaming Replication on win32
Date
Msg-id 22854.1264374191@sss.pgh.pa.us
Whole thread Raw
In response to Re: Streaming Replication on win32  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Streaming Replication on win32  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
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.

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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Streaming Replication on win32
Next
From: Simon Riggs
Date:
Subject: Re: default_language