Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>
Date: 2026-01-14T22:56:50Z
Lists: pgsql-hackers
On Wed, Jan 14, 2026 at 2:16 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote: > All changes in those 3 additional patches look totally reasonable to me. Thanks, I'll plan to squash those in v5, and probably kick 0005 out into its own thread to give people a chance to object even if they're ignoring the grease stuff. > > I'd like reserve a (protected?) wiki page, or something of the sort, > > that we can point people to directly if they hit any grease failures. > > "Server screwed up" is probably not enough context for a typical user > > to know what to do next. > > Seems sensible to have a place to explain something to authors. Why not > put it directly in the protocol docs though? (I'd be fine with a wiki > too, but a docs page is protected by definition) At the moment I can think of two reasons to put a "landing page" for this in the wiki: - Suggested improvements by users who land there can be made immediately/cheaply/ephemerally, without either increasing the revert burden mid-beta or making a committer feel that they have to wait to get it "perfect" (because otherwise they flood the Postgres commit graph with wiki-sized edits that are just going to be reverted anyway). I think this grease phase will work best if we can be maximally responsive to the people who take the time to talk to us. - Informal, personal wiki voice (plus the ability to see a recent edit date -- "yes, we're paying attention to you") seems like a better way to encourage beta users to file bugs than formal project documentation voice. YMMV on that. > Both the patch split and max_protocol_version=grease sound reasonable to > me. I'd definitely like to keep all the grease code present on the main > branch, so we can keep using grease by default there. > > I think max_protocol_version=grease makes a lot of sense. Because we > really want to make it as easy as possible for people to try out their > implementation of the negotation (see this for example[1]) Yeah, I'd like to have that ability too. I don't know that I can commit to writing or reviewing that amount of code for 19, though. (And maybe there are lessons we'll learn during beta that can inform a better production feature?) --Jacob
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
libpq: Grease the protocol by default
- 4966bd3ed95e 19 (unreleased) landed
-
libpq: Prepare for protocol grease during 19beta
- d8d7c5dc8f74 19 (unreleased) landed
-
doc: Expand upon protocol versions and extensions
- e3d37853ecd5 19 (unreleased) landed
-
libpq_pipeline: Test the default protocol version
- 9b9eaf08ab2d 19 (unreleased) landed