Re: Using PQexecQuery in pipeline mode produces unexpected Close messages

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: alvherre(at)alvh(dot)no-ip(dot)org, daniele(dot)varrazzo(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Using PQexecQuery in pipeline mode produces unexpected Close messages
Date: 2022-06-16 01:41:21
Message-ID: 20220616.104121.1499221777899715.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

At Thu, 16 Jun 2022 10:34:22 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> At Wed, 15 Jun 2022 14:56:42 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> > Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > > So, git archaeology led me to this thread
> > > https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql
> > > which is why we added that message in the first place.
> >
> > Um. Good thing you looked. I doubt we want to revert that change now.
> >
> > > Alternatives:
> > > - Have the client not complain if it gets CloseComplete in idle state.
> > > (After all, it's a pretty useless message, since we already do nothing
> > > with it if we get it in BUSY state.)
> >
> > ISTM the actual problem here is that we're reverting to IDLE state too
> > soon. I didn't try to trace down exactly where that's happening, but
>
> Yes. I once visited that fact but also I thought that in the
> comparison with non-pipelined PQsendQuery, the three messages look
> extra. Thus I concluded (at the time) that removing Close is enough
> here.
>
> > I notice that in the non-pipeline case we don't go to IDLE till we've
> > seen 'Z' (Sync). Something in the pipeline logic must be jumping the
> > gun on that state transition.
>
- PQgetResult() resets the state to IDLE when not in pipeline mode.

D... the "not" should not be there.

+ PQgetResult() resets the state to IDLE while in pipeline mode.

> fe-exec.c:2171
>
> > if (conn->pipelineStatus != PQ_PIPELINE_OFF)
> > {
> > /*
> > * We're about to send the results of the current query. Set
> > * us idle now, and ...
> > */
> > conn->asyncStatus = PGASYNC_IDLE;
>
> And actually that code let the connection state enter to IDLE before
> CloseComplete. In the test case I posted, the following happens.
>
> PQsendQuery(conn, "SELECT 1;");
> PQsendFlushRequest(conn);
> PQgetResult(conn); // state enters IDLE, reads down to <CommandComplete>
> PQgetResult(conn); // reads <CloseComplete comes>
> PQpipelineSync(conn); // sync too late
>
> Pipeline feature seems intending to allow PQgetResult called before
> PQpipelineSync. And also seems allowing to call QPpipelineSync() after
> PQgetResult().
>
> I haven't come up with a valid *fix* of this flow..

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-06-16 03:07:47 Re: Using PQexecQuery in pipeline mode produces unexpected Close messages
Previous Message Kyotaro Horiguchi 2022-06-16 01:34:22 Re: Using PQexecQuery in pipeline mode produces unexpected Close messages

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-06-16 01:55:04 Re: Modest proposal to extend TableAM API for controlling cluster commands
Previous Message Kyotaro Horiguchi 2022-06-16 01:34:22 Re: Using PQexecQuery in pipeline mode produces unexpected Close messages