| From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | 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 09:00:50 |
| Message-ID: | m2y6jqqzst.fsf@hi-media.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
dim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marko Kreen | 2010-01-22 10:28:29 | Re: Streaming Replication on win32 |
| Previous Message | Huda Booley (huda@careerjunction.co.za) | 2010-01-22 08:42:33 | Standby server lagging behind |