| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> | 
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> | 
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Streaming Replication on win32 | 
| Date: | 2010-01-21 12:46:17 | 
| Message-ID: | 4B584C99.8090004@enterprisedb.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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.
-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com
| Attachment | Content-Type | Size | 
|---|---|---|
| be-win32-interruptible-dblink-1.patch | text/x-diff | 5.4 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2010-01-21 13:44:15 | Streaming replication and a disk full in primary | 
| Previous Message | Dave Page | 2010-01-21 12:37:01 | Re: 8.5 vs. 9.0 |