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

Re: Streaming Replication on win32

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
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-17 20:22:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Magnus Hagander wrote:
> 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. 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.

Hmm, contrib/dblink probably has the same issue then.

We could replace the blocking PQexec() calls with PQsendQuery(), and use
 the emulated version of select() to wait.

> From what I can tell, this indicates that pq_getbyte_if_available() is
> not working - because it's supposed to never block, right?

Right, it's not supposed to block.

> This could be because the win32 socket emulation layer simply wasn't
> designed to deal with non-blocking sockets. Specifically, it actually
> *always* sets the socket to non-blocking mode, and then uses that to
> properly emulate how sockets work under unix.

I presume the win32 emulation layer can be taught about non-blocking
sockets? Or maybe pq_getbyte_if_available() can be implemented using
some other simpler method on Windows.

  Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2010-01-17 20:34:12
Subject: Re: Git out of sync vs. CVS
Previous:From: Peter EisentrautDate: 2010-01-17 20:19:08
Subject: parallel regression test output

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