At Tue, 21 Jun 2022 11:42:59 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> At Fri, 17 Jun 2022 20:31:50 +0200, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in
> > Others to think about:
> >
> > PQisBusy (I think no changes are needed),
>
> Agreed.
>
> > PQfn (I think it should accept a call in PGASYNC_PIPELINE_IDLE mode;
> > fully untested in pipeline mode),
>
> Does a PQ_PIPELINE_OFF path need that? Rather I thought that we need
> Assert(!conn->asyncStatus != PGASYNC_PIPELINE_IDLE) there. But anyway
> we might need a test for this path.
In the attached, PQfn() is used while in pipeline mode and
PGASYNC_PIPELINE_IDLE. Both error out and effectivelly no-op.
> > PQexitPipelineMode (I think it needs to return error; needs test case),
>
> Agreed about test case. Currently the function doesn't handle
> PGASYNC_IDLE so I thought that PGASYNC_PIPELINE_IDLE also don't need a
> care. If the function treats PGASYNC_PIPELINE_IDLE state as error,
> the regression test fails (but I haven't examine it furtuer.)
PQexitPipelineMode() is called while PGASYNC_PIPELINE_IDLE.
> > PQsendFlushRequest (I think it should let through; ditto).
>
> Does that mean exit without pushing 'H' message?
I didn't do anything on this in the sttached.
By the way, I noticed that "libpq_pipeline uniqviol" intermittently
fails for uncertain reasons.
> result 574/575: pipeline aborted
> ...........................................................
> done writing
>
> libpq_pipeline:1531: got unexpected NULL
The "...........done writing" is printed too late in the error cases.
This causes the TAP test fail, but I haven't find what's happnening at
the time.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center