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-02 19:02:09
Message-ID: 608d9d2f-f102-9266-8802-57188a552a78@timescale.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

A few notes:

> + else if (beresp == 'v')
> + {
> + if (pqGetNegotiateProtocolVersion3(conn))
> + {
> + /* We'll come back when there is more data */
> + return PGRES_POLLING_READING;
> + }
> + /* OK, we read the message; mark data consumed */
> + conn->inStart = conn->inCursor;
> + goto error_return;
> + }

This new code path doesn't go through the message length checks that are
done for the 'R' and 'E' cases, and pqGetNegotiateProtocolVersion3()
doesn't take the message length to know where to stop anyway, so a
misbehaving server can chew up client resources.

It looks like the server is expecting to be able to continue the
conversation with a newer client after sending a
NegotiateProtocolVersion. Is an actual negotiation planned for the future?

I think the documentation on NegotiateProtocolVersion (not introduced in
this patch) is misleading/wrong; it says that the version number sent
back is the "newest minor protocol version supported by the server for
the major protocol version requested by the client" which doesn't seem
to match the actual usage seen here.

Thanks,
--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-11-02 19:09:47 Re: ssl tests aren't concurrency safe due to get_free_port()
Previous Message Tom Lane 2022-11-02 18:55:04 Re: spinlock support on loongarch64