Re: Streaming Replication on win32

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, 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 10:28:29
Message-ID: e51f66da1001220228r415c435ayac8423ebcba4a8af@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/22/10, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>
> > Joe Conway wrote:
> >> 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?
> >
> > The problem only applies to libpq calls from the backend. Client apps
> > are not affected, only backend modules. If there's any other modules out
> > there that use libpq, then yes, those have a problem too.
>
>
> plproxy comes to mind.

Thats interesting. PL/Proxy deos not use PQexec, it uses async
execution and waits on sockets with plain select() called
from code compiled with backend headers.

So it seems to be already using pgwin32_select(). Or not?

--
marko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-01-22 10:32:45 Access to dynamic SQL in PL/pgSQL
Previous Message Dimitri Fontaine 2010-01-22 09:00:50 Re: Streaming Replication on win32