Re: Pipeline mode and PQpipelineSync()

From: Alvaro Herrera <alvaro(dot)herrera(at)2ndquadrant(dot)com>
To: Boris Kolpackov <boris(at)codesynthesis(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: Pipeline mode and PQpipelineSync()
Date: 2021-07-08 13:57:32
Message-ID: 202107081357.xbplnti7szms@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-Jul-08, Boris Kolpackov wrote:

> Alvaro Herrera <alvaro(dot)herrera(at)2ndquadrant(dot)com> writes:
>
> > Hmm ... aren't you trying to read more results than you sent queries?
>
> Hm, but should I be able to? Or, to put another way, should PQisBusy()
> indicate there is a result available without me sending a query for it?
> That sounds very counter-intuitive to me.

That seems a fair complaint, but I think PQisBusy is doing the right
thing per its charter. It is documented as "would PQgetResult block?"
and it is returning correctly that PQgetResult would not block in that
situation, because no queries are pending. I think we would regret
changing PQisBusy in the way you suggest.

I think your expectation is that we would have an entry point for easy
iteration; a way to say "if there's a result set to be had, can I have
it please, otherwise I'm done iterating". That seems a reasonable ask,
but PQisBusy is not that. Maybe it would be PQisResultPending() or
something like that. I again have to ask the RMT what do they think of
adding such a thing to libpq this late in the cycle.

--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-07-08 13:58:35 Re: SHA-1 FIPS - compliance
Previous Message Bruce Momjian 2021-07-08 13:51:47 Re: visibility map corruption