Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
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-21T19:14:35Z
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 →
-
libpq: Add min/max_protocol_version connection options
- 285613c60a7a 18.0 landed
-
libpq: Handle NegotiateProtocolVersion message differently
- 5070349102af 18.0 landed
-
Add PQfullProtocolVersion() to surface the precise protocol version.
- cdb6b0fdb0b2 18.0 landed
-
Do not hardcode PG_PROTOCOL_LATEST in NegotiateProtocolVersion
- 516b87502dc1 18.0 landed
-
libpq: Handle NegotiateProtocolVersion message
- bbf9c282ce92 16.0 cited
-
Provide for forward compatibility with future minor protocol versions.
- ae65f6066dc3 11.0 cited
On Tue, Aug 20, 2024 at 3:17 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote: > > On Tue, 20 Aug 2024 at 23:48, Jacob Champion > <jacob.champion@enterprisedb.com> wrote: > > That guarantee (if adopted) would also make it possible for my use > > case to proceed correctly, since a libpq client can still speak 3.0 > > packets on the socket safely. > > Not necessarily (at least not how I defined it). If a protocol > parameter has been configured (possibly done by default by libpq), > then that might not be the case anymore. So, you'd also need to > compare the current values of the protocol parameters to their > expected value. With your definition, I agree. But I was about to sneakily suggest (muahaha) that if you want to go that route, maybe protocol extensions need to provide their own forward compatibility statements. Whether via the same mechanism, or with something like criticality. > > But in that case, PQprotocolVersion > > should keep returning 3, because there's an explicit reason to care > > about the major version by itself. > > I agree that there's a reason to care about the major version then, > but it might still be better to fail hard for people that care about > protocol details. Maybe? In the span of a couple of days we've gone from "minor versions are actually major versions and we will break all intermediaries all the time" to "maybe not, actually". It's difficult for me to reason through things that quickly. And on some level, that's fine and expected, if we're still at the debate-and-design stage. But personally I'd hoped that most of the conversation around something this disruptive would be about what's going to break and what's not, with the goal of making the broken set as small as possible in exchange for specific benefits. Instead it seems like use cases are having to justify themselves to avoid being broken, which is not really the stance I want to see from a protocol maintainer. Especially not if your stated goal is to bump versions whenever we want (which, just for the record, I do not agree with). Put another way: we've seen that our protocol-version joint has rusted [1, 2]. I agree that needs to be fixed. But I also believe that we shouldn't try to smash the joint open with a hammer, and that belief seems philosophically at odds with the approach being taken upthread. So if I'm the only one who feels this way, please someone let me know so I can bow out instead of throwing up roadblocks... I don't want to be a distraction from incremental protocol improvements. --Jacob [1] https://en.wikipedia.org/wiki/Protocol_ossification [2] https://www.imperialviolet.org/2016/05/16/agility.html