From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Joe Conway <mail(at)joeconway(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:33:50 |
Message-ID: | 4B5946CE.2090104@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joe Conway wrote:
> +#ifdef WIN23
> ^^^^^
> I assume you meant WIN32 here ;-)
Yeah. I admit I haven't tested this on Windows, I just commented out
those #ifdef's and tested on Linux. Will need to verify that this
actually solves the problem on Windows before committing.
> +#define PQexec(conn, command) dblink_PQexec(conn, command)
> +#define PQconnectdb(conninfo) dblink_PQconnectdb(conninfo)
>
> 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.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2010-01-22 06:49:01 | Re: Streaming Replication on win32 |
Previous Message | KaiGai Kohei | 2010-01-22 05:45:15 | Re: Largeobject Access Controls (r2460) |