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

Re: Streaming Replication on win32

From: Joe Conway <mail(at)joeconway(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming Replication on win32
Date: 2010-01-22 06:49:01
Message-ID: 4B594A5D.5070702@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 01/21/2010 10:33 PM, Heikki Linnakangas wrote:
> Joe Conway wrote:
>> I have not been really following this thread, but why can't we put the
>> "#ifdef WIN32" and special definition of these functions into libpq. I
>> don't understand why we need special treatment for dblink.
> 
> The problem is that select() function on Windows isn't interrupted by
> signals. That's because Unix-style signals don't exist on Windows, but
> we've emulated them in the server with pipes. The select() function
> doesn't know about that hack, so in the backend, we've replaced it with
> pgwin32_select() that does, using a #define.

Ah, thanks for the synopsis.

> libpq doesn't use that #define and pgwin32_select(), because that's a
> backend function. It won't work in regular client applications.
> 
> If we just moved those dblink_PQexec/PQconnectdb() functions to libpq,
> they wouldn't use pgwin32_select() and would thus be useless.

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?

Joe


In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-01-22 07:16:29
Subject: Re: quoting psql varible as identifier
Previous:From: Heikki LinnakangasDate: 2010-01-22 06:33:50
Subject: Re: Streaming Replication on win32

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