On 01/21/2010 04:46 AM, Heikki Linnakangas wrote: > Heikki Linnakangas wrote: >> Magnus Hagander wrote: >>> 2010/1/17 Heikki Linnakangas <heikki.linnakan...@enterprisedb.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.
+#ifdef WIN23 ^^^^^ I assume you meant WIN32 here ;-) +#define PQexec(conn, command) dblink_PQexec(conn, command) +#define PQconnectdb(conninfo) dblink_PQconnectdb(conninfo) I have not been really following this thread, but why can't we put the "#ifdef WIN32" and special definition of these functions into libpq. I don't understand why we need special treatment for dblink. Joe
signature.asc
Description: OpenPGP digital signature