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-24 22:33:39
Message-ID: 4B5CCAC3.7080104@joeconway.com (view raw or flat)
Thread:
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

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-01-24 22:36:52
Subject: Re: Streaming Replication on win32
Previous:From: Andrew DunstanDate: 2010-01-24 22:29:47
Subject: Re: 8.5 vs. 9.0, Postgres vs. PostgreSQL

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