Horton

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

Jelte Fennema-Nio <postgres@jeltef.nl>

View thread
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Jacob Burroughs <jburroughs@instructure.com>, Dave Cramer <davecramer@gmail.com>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Pavel Stehule <pavel.stehule@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Peter Eisentraut <peter@eisentraut.org>, Daniele Varrazzo <daniele.varrazzo@gmail.com>
Date: 2024-08-20T19:55:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. libpq: Add min/max_protocol_version connection options

  2. libpq: Handle NegotiateProtocolVersion message differently

  3. Add PQfullProtocolVersion() to surface the precise protocol version.

  4. Do not hardcode PG_PROTOCOL_LATEST in NegotiateProtocolVersion

  5. libpq: Handle NegotiateProtocolVersion message

  6. Provide for forward compatibility with future minor protocol versions.

On Tue, 20 Aug 2024 at 19:31, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> It's applicable to the use case I was talking about with Jelte. A
> libpq client dropping down to the socket level is relying on
> (implicit, currently undocumented/undecided, possibly incorrect!)
> intermediary guarantees that the protocol provides for a major
> version. I'm hoping we can provide some, since we haven't broken
> anything yet. If we decide we can't, then so be it -- things will
> break either way -- but it's still strange to me that we'd be okay
> with literally zero forward compatibility and still call that a "minor
> version".

I think one compatibility guarantee that we might want to uphold is
something like the following: After completing the initial connection
setup, a server should only send new message types or new fields on
existing message types when the client has specifically advertised
support for that message type in one of two ways:
1. By configuring a specific protocol parameter
2. By sending a new message type or using a new field that implicitly
advertises support for the new message type/fields. In this case the
message should be of a request-response style, the server cannot
assume that after the request-response communication happened this new
message type is still supported by the client.

The reasoning for this was discussed a while back upthread: This would
be to allow a connection pooler (like PgBouncer) to have a pool of the
highest minor version that the pooler supports e.g 3.8, but then it
could still hand out these connections to clients that connected to
the pooler using a lower version. Without having these clients receive
messages that they do not support.

Another way of describing this guarantee: If a client connects using
3.8 and configures no protocol parameters, the client needs to handle
anything 3.8 specific that the handshake requires (such as longer
cancel token). But then after that handshake it can choose to send
only 3.0 packets and expect to receive only 3.0 packets back.