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

Re: Streaming Replication on win32

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming Replication on win32
Date: 2010-01-18 14:43:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/1/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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?

AFAIK, no. We can somehow control the link order when we link with the
import library, but that would require us to do it at link time,
meaning libpq would be linked to postgres.exe --> FAIL.

Another option is to load the select() function on runtime, by having
libpq examine the list of loaded modules for postgres.exe.. But that
seems a lot uglier than providing some kind of callback for it.

 Magnus Hagander

In response to

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-01-18 14:46:02
Subject: Re: Streaming Replication on win32
Previous:From: Simon RiggsDate: 2010-01-18 14:42:43
Subject: Re: Streaming replication, and walsender during recovery

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