On Sat, Apr 3, 2010 at 12:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I disapprove of the whole approach, actually. The right way to fix this
> is to not touch or replace libpq at all, but to change walreceiver to
> use libpq's async-query facilities directly. Instead of PQexec, use
> PQsendQuery and then a loop involving PQisBusy, PQgetResult, etc.
Yes.
> You've more or less done that loop, but you've put it in the wrong
> place.
OK. I'll reconsider about how to use those asynchronous libpq functions.
But, if possible, could you point out where "the right place" is?
> The larger point is that I don't believe this issue exists only on
> Windows. I think we're going to want something like this on all
> platforms, and that implies supporting poll() not just select() for the
> waiting part.
OK. I'll change the part so that poll() is used if HAVE_POLL is defined,
select() otherwise.
> The patch also seems confused about whether it's intending to be a
> general-purpose solution or not. You can maybe take some shortcuts
> if it's only going to be for walreceiver, but if you're going to put
> it in dblink it is *not* acceptable to take shortcuts like not
> processing errors completely.
OK. I'll address this problem. Since PGconn->errorMessage cannot be
updated from outside of libpq, I'm thinking of making the caller give
the StringInfo variable as a parameter to pgwin32_PQexec(), and
putting error messages in it. Then the caller use the StringInfo
instead of PQerrorMessage(PGconn), to get the error messages.
And ISTM that dblink needs to hold the StringInfo using hash as
do the PGconn.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center