Re: Streaming Replication on win32
Joe Conway <mail@joeconway.com>
From: Joe Conway <mail@joeconway.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Magnus Hagander <magnus@hagander.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-01-24T22:33:39Z
Lists: pgsql-hackers
On 01/21/2010 11:19 PM, Heikki Linnakangas wrote: > 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. Sorry for being thick -- I'm still missing something. I don't understand why any user program using libpq/PQexec running on Windows does not have the same issue. Or to put it another way, why does this only apply to libpq calls from backend modules? > A generic fix would be nice. Putting the wrapper functions in a new > header file that's included in all backend modules that want to use > libpq would work. Maybe the new header file could even be #included from > libpq-fe.h, when compiling backend code (#ifndef FRONTEND), so you > wouldn't need to modify dblink, walreceiver, or any 3rd party modules > that use libpq at all. I'll go ahead and do this if there is consensus for it. Joe