Re: [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Higuchi, Daisuke" <higuchi(dot)daisuke(at)jp(dot)fujitsu(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write
Date: 2017-02-15 06:31:41
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I think the patch as presented probably isn't quite what we want,
> because it waits synchronously for the second result to be ready.
> Note that the wait for the first result is asynchronous: we check
> PQisBusy and return without progressing the state machine until the
> latter returns false; only then do we call PQgetResult().

OK, I have been poking at this problem. I think that we need to
introduce a new state in ConnStatusType telling "please consume all
results until PQgetResult returns NULL" which is CONNECTION_CONSUME in
the patch attached. And as long as all the results are not consumed,
the loop just keeps going. If more messages are being waited for with
PGisBusy returning true, then the loop requests for more data to read
by switching back to PGRES_POLLING_READING.

By the way, I am noticing as well that libpq.sgml is missing a
reference to CONNECTION_CHECK_WRITABLE. This should be present as
applications calling PQconnectPoll() could face such a status. I have
fixed this issue as well in the patch attached.

Attachment Content-Type Size
pqsendquery-fix-v3.patch application/octet-stream 3.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Seki, Eiji 2017-02-15 06:33:29 Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags
Previous Message Masahiko Sawada 2017-02-15 06:11:02 Re: Transactions involving multiple postgres foreign servers