Re: libpq support for NegotiateProtocolVersion

From: Jacob Champion <jchampion(at)timescale(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq support for NegotiateProtocolVersion
Date: 2022-11-11 22:28:41
Message-ID: a5c5783d-73f3-acbc-997f-1649a7406029@timescale.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/11/22 07:13, Peter Eisentraut wrote:
> On 09.11.22 00:08, Jacob Champion wrote:
>> pqGetNegotiateProtocolVersion3() is still ignoring the message length,
>> though; it won't necessarily stop at the message boundary.
>
> I don't follow. The calls to pqGetInt(), pqGets(), etc. check the
> message length.

I may be missing something obvious, but I don't see any message length
checks in those functions, just bounds checks on the connection buffer.

> Do you have something else in mind? Can you give an
> example or existing code?

Sure. Consider the case where the server sends a
NegotiateProtocolVersion with a reasonable length, but then runs over
its own message (either by sending an unterminated string as one of the
extension names, or by sending a huge extension number). When I test
that against a client on my machine, it churns CPU and memory waiting
for the end of a message that will never come, even though it had
already decided that the maximum length of the message should have been
less than 2K.

Put another way, why do we loop around and poll for more data when we
hit the end of the connection buffer, if we've already checked at this
point that we should have the entire message buffered locally?

>+ initPQExpBuffer(&buf);
>+ if (pqGetInt(&tmp, 4, conn) != 0)
>+ return EOF;

Tangentially related -- I think the temporary PQExpBuffer is being
leaked in the EOF case.

--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-11-11 22:40:45 Re: Document WAL rules related to PD_ALL_VISIBLE in README
Previous Message Jeff Davis 2022-11-11 22:14:10 Document WAL rules related to PD_ALL_VISIBLE in README