| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, 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-15 18:56:42 |
| Message-ID: | 532816.1655319402@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-06-15 19:32:04 | Re: pg_upgrade (12->14) fails on aggregate |
| Previous Message | Alvaro Herrera | 2022-06-15 18:26:33 | Re: Using PQexecQuery in pipeline mode produces unexpected Close messages |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-06-15 19:32:04 | Re: pg_upgrade (12->14) fails on aggregate |
| Previous Message | Imseih (AWS), Sami | 2022-06-15 18:45:38 | [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity |