2010/1/24 Joe Conway <mail@joeconway.com>:
> On 01/21/2010 11:19 PM, Heikki Linnakangas wrote:
>> Joe Conway wrote:
>>> OK, so now I see why we want this fixed for dblink and walreceiver, but
>>> doesn't this approach leave every other WIN32 libpq client out in the
>>> cold? Is there nothing that can be done for the general case, or is it a
>>> SMOP?
>>
>> The problem only applies to libpq calls from the backend. Client apps
>> are not affected, only backend modules. If there's any other modules out
>> there that use libpq, then yes, those have a problem too.
>
> 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. We faked them for
PostgreSQL so we didn't have to rewrite large parts of how the backend
deals with those things. I don't know any other software that does -
and especially not client side software.
So yeah, you could say they are affected insofar that their calls will
be blocked as well, but if they are Windows apps they are probably
designed to deal with it. It's the common way for such calls to behave
on the platform.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
