PSA: Planning to grease protocol connections during 19beta
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t52859psql -h localhost -U postgresBuilt from patchset v15 (message #15), September 01, 2026 at 04:42 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t52859_15 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t52859_15 && git checkout t52859_15Patchset v15 (message #15) is on t52859_15
I want to make sure this doesn't take anyone by surprise: I'm planning
to get Jelte's "grease" patch into shape for a commit some time in
January.
https://commitfest.postgresql.org/patch/6157/
If you're unfamiliar with the concept of greasing [1]https://datatracker.ietf.org/doc/draft-edm-protocol-greasing/, one way to
think of it is that we're inverting Postel's Law: we will be very
liberal in what we send during connection, and then fail the
connection outright if a server doesn't reply with a
NegotiateProtocolVersion that points out our nonsense. This helps
build confidence that a future bump in our protocol defaults won't
cause operational failures due to buggy implementations (proxies,
bouncers, other servers).
The plan is to grease the minor version number and at least one
protocol extension during the 19 beta, then revert partway through (as
tracked by a mid-beta Open Item). Users who run into trouble during
beta can revert to the previous behavior by setting
max_protocol_version=3.0, ideally *after* they file a bug report for
the peer implementation. Documenting that, in a way that's effective
for both users and implementers, is something that still needs work
for the current patchset.
So, if anyone has objections to the overall idea, now is a great time
to say so. (Here is fine, but preferably also on the patch thread for
posterity.)
Thanks!
--Jacob
[1]: https://datatracker.ietf.org/doc/draft-edm-protocol-greasing/
On Tue, Dec 9, 2025 at 5:16 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
I want to make sure this doesn't take anyone by surprise: I'm planning
to get Jelte's "grease" patch into shape for a commit some time in
January.
As of January 54th, this is committed.
I wanted to get people's thoughts on communication. As it stands now,
beta users will be directed towards our own documentation [1]https://www.postgresql.org/docs/devel/libpq-connect.html#LIBPQ-CONNECT-MAX-PROTOCOL-VERSION when
they hit a grease failure. But personally, I'd like the landing page
to be on the wiki, for several reasons:
- It can be written in a more casual voice, and go into detail that
would be out of place in a docs note
- It's easier to change quickly in response to end user feedback, if
we receive any
- It can remain in place after the beta period ends
But having libpq link to a wiki page makes that page a vandalism
target. Can a wiki page be protected in a way that still lets
committers edit it? Is there a third option that works better than the
docs or the wiki?
--Jacob
[1]: https://www.postgresql.org/docs/devel/libpq-connect.html#LIBPQ-CONNECT-MAX-PROTOCOL-VERSION
Jacob Champion <jacob.champion@enterprisedb.com> writes:
I wanted to get people's thoughts on communication. As it stands now,
beta users will be directed towards our own documentation [1] when
they hit a grease failure. But personally, I'd like the landing page
to be on the wiki, for several reasons:
- It can be written in a more casual voice, and go into detail that
would be out of place in a docs note
- It's easier to change quickly in response to end user feedback, if
we receive any
- It can remain in place after the beta period ends
But having libpq link to a wiki page makes that page a vandalism
target. Can a wiki page be protected in a way that still lets
committers edit it? Is there a third option that works better than the
docs or the wiki?
We have the ability to lock down a wiki page, but I believe that means
nobody can edit it until a wiki admin unlocks it. That might be the
way to go here though. I concur with your reasoning that the main
docs are a less-good place.
regards, tom lane
On Mon, Feb 23, 2026 at 12:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
We have the ability to lock down a wiki page, but I believe that means
nobody can edit it until a wiki admin unlocks it. That might be the
way to go here though. I concur with your reasoning that the main
docs are a less-good place.
Okay, sounds good. I've created
https://wiki.postgresql.org/wiki/Grease for now; I'll work on filling
it in. I think FAQ-style might work well for this format.
--Jacob
On Thu, Feb 26, 2026 at 8:30 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
Okay, sounds good. I've created
https://wiki.postgresql.org/wiki/Grease for now; I'll work on filling
it in. I think FAQ-style might work well for this format.
I worked on a rough draft last week, and it looks like it's now being
cached for anonymous users too:
https://wiki.postgresql.org/wiki/Grease
I went for heavy editorializing and conversational style. One section
for users, another for devs.
Something I'm struggling with is whether (and how) to have people let
us know when they've hit this, so that we know that the campaign is
working. I have some language to that effect in the "What do I need to
do?" section, but I don't really know what list I should point to, if
any, nor what they should say so that they don't confuse the list
regulars. I'm considering removing that part of the call to action.
--Jacob
On Mon, Apr 13, 2026 at 11:58 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
Something I'm struggling with is whether (and how) to have people let
us know when they've hit this, so that we know that the campaign is
working. I have some language to that effect in the "What do I need to
do?" section, but I don't really know what list I should point to, if
any, nor what they should say so that they don't confuse the list
regulars. I'm considering removing that part of the call to action.
I have removed this.
Are there any opinions on whether [1]https://wiki.postgresql.org/wiki/Grease in its current state is an
improvement over [2]https://www.postgresql.org/docs/devel/libpq-connect.html#LIBPQ-CONNECT-MAX-PROTOCOL-VERSION as a landing page for users who hit this? I would
only swap out the link if I can get the wiki page protected.
Thanks,
--Jacob
[1]: https://wiki.postgresql.org/wiki/Grease
[2]: https://www.postgresql.org/docs/devel/libpq-connect.html#LIBPQ-CONNECT-MAX-PROTOCOL-VERSION
On Tue, May 5, 2026, 23:27 Jacob Champion <jacob.champion@enterprisedb.com>
wrote:
Are there any opinions on whether [1] in its current state is an
improvement over [2] as a landing page for users who hit this? I would
only swap out the link if I can get the wiki page protected.
I very much like the wiki page. Thanks for writing that. I would definitely
prefer that to be the landing page (assuming it can be locked down).
Show quoted text
On Wed, May 6, 2026 at 1:25 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
I very much like the wiki page. Thanks for writing that.
Thank you for writing the feature!
I would definitely prefer that to be the landing page (assuming it can be locked down).
Sounds good; I will ask around.
--Jacob
On Wed, May 6, 2026 at 8:05 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
I would definitely prefer that to be the landing page (assuming it can be locked down).
Sounds good; I will ask around.
Joe did this for us [1]/messages/by-id/72dd6202-3346-40b3-be3e-7ae22f914302@joeconway.com -- thanks Joe! -- and I've pushed the commit
to link to it.
So: thanks everybody! Now we get to see if anything happens.
--Jacob
[1]: /messages/by-id/72dd6202-3346-40b3-be3e-7ae22f914302@joeconway.com
On Mon, Apr 13, 2026, 20:58 Jacob Champion <jacob.champion@enterprisedb.com>
wrote:
Something I'm struggling with is whether (and how) to have people let
us know when they've hit this, so that we know that the campaign is
working. I have some language to that effect in the "What do I need to
do?" section, but I don't really know what list I should point to, if
any, nor what they should say so that they don't confuse the list
regulars. I'm considering removing that part of the call to action.
I think it'd be good if they notify us too. So we can get a sense of
whether it's "safe enough" to bump the protocol version at some point
and/or we can bug important offenders that we have some sway over. How
about adding something like this to the wiki page:
Please also report the issue to the pgsql-hackers mailinglist using the
[grease] tag at the start of the subject and include a link to the upstream
issue (if it's on a public issue tracker). As an example:
To: pgsql-hackers@lists.postgresql.org
Subject: [grease] ExampleProxy fails grease check
Body:
I'm using ExampleProxy and it's failing the grease check. I've reported the
issue upstream at https://example.com/issues/1234
On Wed, Jun 3, 2026 at 1:04 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
I think it'd be good if they notify us too. So we can get a sense of whether it's "safe enough" to bump the protocol version at some point and/or we can bug important offenders that we have some sway over. How about adding something like this to the wiki page:
Please also report the issue to the pgsql-hackers mailinglist using the [grease] tag at the start of the subject and include a link to the upstream issue (if it's on a public issue tracker). As an example:
To: pgsql-hackers@lists.postgresql.org
Subject: [grease] ExampleProxy fails grease check
Body:
I'm using ExampleProxy and it's failing the grease check. I've reported the issue upstream at https://example.com/issues/1234
Thanks! Something like that seems reasonable to me, yeah.
Any objections here to making -hackers the landing point? I wouldn't
want to do that for a released feature, but for a beta-only thing, I
feel like the audience will be small enough to avoid accidentally
DoSing ourselves.
--Jacob
On Wed, 3 Jun 2026 at 20:38, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
Any objections here to making -hackers the landing point? I wouldn't
want to do that for a released feature, but for a beta-only thing, I
feel like the audience will be small enough to avoid accidentally
DoSing ourselves.
If it becomes too noisy we can change the page to suggest people to
report it some other way Another option would be to dedicate a wiki
page to it, but wiki edit permissions are non-trivial to get these
days. I prefer making it easy for people to report issues to us,
unless it becomes an actual problem.
On Wed, Jun 3, 2026 at 12:30 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
If it becomes too noisy we can change the page to suggest people to
report it some other way
Yep! Hearing no objections so far, I'll copy-edit a version of your
suggestion this morning and send it to the wiki admins.
Thanks!
--Jacob
On Thu, Jun 4, 2026 at 8:16 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
Yep! Hearing no objections so far, I'll copy-edit a version of your
suggestion this morning and send it to the wiki admins.
Done. Thank you!
--Jacob
On Tue, Dec 9, 2025 at 5:16 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
The plan is to grease the minor version number and at least one
protocol extension during the 19 beta, then revert partway through (as
tracked by a mid-beta Open Item).
And now it's time to revert. Proposed patch attached.
Though we didn't get any [grease] emails to the list, I think this was
a success. There are recent issues and PRs on GitHub that reference
this, and we flushed out an issue with Debian's upgrade wrappers that
matches the bug that pg_upgrade itself had, and there's even anecdotal
evidence that a correct negotiation implementation can survive contact
with Copilot's incorrect review advice. Woohoo!
Jelte, thanks again for the idea. I think we should try to develop a
production implementation of this for PG20.
--Jacob
On Tue, Aug 25, 2026, 19:23 Jacob Champion <jacob.champion@enterprisedb.com>
wrote:
On Tue, Dec 9, 2025 at 5:16 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:The plan is to grease the minor version number and at least one
protocol extension during the 19 beta, then revert partway through (as
tracked by a mid-beta Open Item).And now it's time to revert. Proposed patch attached.
Sounds good to me. One clarification: do you intend to revert only on the
RELEASE_19_STABLE branch or also on master? I think we could keep master as
is so we continue to grease. Though we should probably update the docs if
we do that, to clarify that it's not just on the PG19 beta period.
Show quoted text
On Wed, Aug 26, 2026 at 3:56 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
Sounds good to me.
Cool.
One clarification: do you intend to revert only on the RELEASE_19_STABLE branch or also on master? I think we could keep master as is so we continue to grease. Though we should probably update the docs if we do that, to clarify that it's not just on the PG19 beta period.
Also on master, since that was the original deal. (If anyone had
concerns about the original proposal, but chose not to speak up
because I promised a revert, they should get a chance to revisit with
the next patch proposal.)
Thanks,
--Jacob