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: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming Replication on win32
Date: 2010-01-18 04:21:41
Message-ID: 27351.1263788501@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Which shows one potentially big problem - since we're calling select()
> from inside libpq, it's not calling our "signal emulation layer
> compatible select()". This means that at this point, walreceiver is
> not interruptible.

Ugh.

> Which also shows itself if I shut down the system -
> the walreceiver stays around, and won't terminate properly. Do we need
> to invent a way for libpq to call back into backend code to do this
> select? We certainly can't have libipq use our version directly -
> since that would break all non-postmaster/postgres processes.

I think that on some platforms, it's possible for the call to select()
from a shlib such as libpq to be captured by a select() provided by the
executable it's loaded into.  Dunno about the linking rules on Windows,
but is there any chance of a workaround that way?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-01-18 04:54:10
Subject: Re: parallel regression test output
Previous:From: Tom LaneDate: 2010-01-18 04:11:40
Subject: Re: pgsql: Fix portalmem.c to avoid keeping a dangling pointer to a cached

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