Re: libpq: pipeline mode might desynchronize client and server

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Ivan Trofimov <i(dot)trofimow(at)yandex(dot)ru>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: libpq: pipeline mode might desynchronize client and server
Date: 2023-11-24 09:50:30
Message-ID: 202311240950.qmsmomjrr76f@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2023-Nov-24, Michael Paquier wrote:

> On Wed, Nov 22, 2023 at 03:13:46AM +0300, Ivan Trofimov wrote:

> > Libpq in pipeline mode considers '< 2TDCEZ' a sufficient response to
> > '> BDESS', when according to specification one more 'Z' is expected.
> > This leads to client <-> server desynchronization, when libpq parses the
> > very next message server sends (which is Z, as expected).
> >
> > A bit more context and a MRE:
> > https://github.com/itrofimow/libpq_protocol_desync
> >
> > I'm pretty sure that this branch https://github.com/postgres/postgres/blob/3af101ce8be8eeb0e8adc61e293b5d12989f68be/src/interfaces/libpq/fe-exec.c#L2124
> > should be adjusted to handle the case and do not match error response
> > against sync query.
>
> Could you attach the test case to the original thread please (assuming
> that this is the same problem)? If this data is deleted by github,
> then any data making a problem reproducible would be lost.

FWIW I started looking at this problem a couple of days ago. I had not
noticed the previous thread.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens)

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-11-24 11:21:39 BUG #18214: poly_contain (@>) hangs forever for input data with zeros and infinities
Previous Message PG Bug reporting form 2023-11-24 08:35:08 BUG #18213: Standby's repeatable read isolation level transaction encountered a "nonrepeatable read" problem