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: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Jacob Champion <jacob.champion@enterprisedb.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-20T16:55:47Z
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 18:42, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> v18 libpq-based clients, if they attempt to connect using v4 and fail, will try again using the v3 connection.  That will retain status quo behavior when something like a connection pooler doesn't understand the new reality.

Having connection latency double when connecting to an older Postgres
is something I'd very much like to avoid. Reconnecting functionally
retains the status quo, but it doesn't retain the expected perf
characteristics. By using a minor protocol version we can easily avoid
this connection latency issue.