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:34:22 |
Message-ID: | 20220616.103422.2111499217922924771.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-06-16 01:41:21 | Re: Using PQexecQuery in pipeline mode produces unexpected Close messages |
Previous Message | Tom Lane | 2022-06-15 19:32:04 | Re: pg_upgrade (12->14) fails on aggregate |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-06-16 01:41:21 | Re: Using PQexecQuery in pipeline mode produces unexpected Close messages |
Previous Message | Mark Dilger | 2022-06-16 01:24:45 | Re: Modest proposal to extend TableAM API for controlling cluster commands |