Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Jelte Fennema-Nio <me@jeltef.nl>
Cc: 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>, hlinnaka <hlinnaka@iki.fi>
Date: 2024-06-04T15:00:20Z
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 Sat, May 25, 2024 at 6:40 AM Jelte Fennema-Nio <me@jeltef.nl> wrote:
> Of the proposed changes so far on the mailing list the only 2 that
> would fall under 1 imho are:
> 1. The ParameterSet message
> 2. Longer than 32bit secret in BackendKeyData

Yeah. I wonder how Heikki thinks he can do (2) without breaking
everything. Maybe just adding an extra, optional, longer field onto
the existing message and hoping that client implementations ignore the
extra field? If that's not good enough, then I don't understand how
that can be done without breaking compatibility in a fundamental and
relatively serious way -- at which point maybe bumping the protocol
version is the right thing to do.

Really, what I'm strongly opposed to is not bumping the version, but
rather doing things that break compatibility such that we need to bump
the version. *If* we have a problem that's sufficiently serious to
justify breaking compatibility anyway, then we don't really lose
anything by bumping the version, and indeed we gain something. I just
want us to be searching for ways to avoid breaking interoperability,
rather than seeking them out. If it becomes impossible for a PG 18 (or
whatever version) server to communicate with earlier servers without
specifying special options, or worse yet at all, then a lot of people
are going to be very sad about that. We will get a bunch of complaints
and a bunch of frustrated users, and they will not be impressed by
vague claims of necessity or desirability. They'll just be mad.

The question for me here is not "what is the theoretically right thing
to do?" but rather "what am I going to tell angry users when they
demand to know why I committed the patch that broke this?". "The old
way was insecure so we had to change it" might be a good enough reason
for people to calm down and stop yelling at me, but "it's no use
having a protocol version if we never bump it" definitely won't be.

-- 
Robert Haas
EDB: http://www.enterprisedb.com