Skip site navigation (1) Skip section navigation (2)

Re: Streaming Replication on win32

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming Replication on win32
Date: 2010-01-24 23:03:11
Message-ID: 22854.1264374191@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> 2010/1/24 Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-01-24 23:18:00
Subject: Re: default_language
Previous:From: Magnus HaganderDate: 2010-01-24 22:36:52
Subject: Re: Streaming Replication on win32

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group