From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Трофимов Иван <i(dot)trofimow(at)yandex(dot)ru> |
Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17948: libpq seems to misbehave in a pipelining corner case |
Date: | 2023-12-01 14:20:28 |
Message-ID: | 202312011420.zmxtoxtvu6ip@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2023-Aug-05, Трофимов Иван wrote:
> We've managed to reproduce client <-> server de-synchronization triggered
> by this, which we are seeing in production.
> Libpq considers '< 2TDCEZ' a sufficient response to '> BDESS', when
> according to specification one more 'Z' is expected.
>
> A bit more context and a MRE:
> https://github.com/itrofimow/libpq_protocol_desync
Does this patch fix the problems? I think the sync loss is because
we're consuming elements from the command queue even when we shouldn't,
because we don't know for an ERROR whether we should do so or not. What
this patch does is a bit of a hack, I think, but it does solve your test
case (and it doesn't break anything else in the tree) AFAICS. I may
have to play some more with it before gaining confidence, though.
Thanks
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Hay dos momentos en la vida de un hombre en los que no debería
especular: cuando puede permitírselo y cuando no puede" (Mark Twain)
Attachment | Content-Type | Size |
---|---|---|
libpq.patch | text/x-diff | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-12-02 02:47:55 | BUG #18221: Unexpected Query Result |
Previous Message | Richard Guo | 2023-12-01 10:07:03 | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower |