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 01:03:56 |
Message-ID: | 4B58F97C.6000501@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/21/2010 04:46 AM, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
>> Magnus Hagander wrote:
>>> 2010/1/17 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
>>>> We could replace the blocking PQexec() calls with PQsendQuery(), and use
>>>> the emulated version of select() to wait.
>>> Hmm. That would at least theoretically work, but aren't there still
>>> places we may end up blocking further down? Or are those ok?
>>
>> There's also PQconnect that needs similar treatment (using
>> PQconnectStart/Poll()), but that's it.
>
> So here's a patch implementing that for contrib/dblink. Walreceiver
> needs the same treatment.
>
> The implementation should be shared between the two, but I'm not sure
> how. We can't just put the wrapper functions to a module in
> src/backend/port/, because the wrapper functions depend on libpq. Maybe
> put them in a new header file as static functions, and include that in
> contrib/dblink/dblink.c and src/backend/replication/libpqwalreceiver.c.
+#ifdef WIN23
^^^^^
I assume you meant WIN32 here ;-)
+#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.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Takahiro Itagaki | 2010-01-22 01:19:26 | Re: Partitioning syntax |
Previous Message | Joe Conway | 2010-01-22 00:57:52 | Re: Fix for memory leak in dblink |