PSA: Planning to grease protocol connections during 19beta

First seen: 2025-12-10 01:16:11+00:00 · Messages: 12 · Participants: 3

Latest Update

2026-06-04 · claude-opus-4-6

Grease Failure Reporting Process — New Discussion

The new messages introduce a concrete proposal for how grease-induced failures should be reported back to the PostgreSQL community. This is a process/communication decision rather than a technical code change.

Key New Decision Point

Jelte Fennema-Nio proposes adding instructions to the wiki page asking users who hit grease failures to report them to pgsql-hackers with a [grease] subject tag and a link to any upstream bug they've filed. He provides a template email format.

Jacob Champion agrees this is reasonable and asks for objections to using pgsql-hackers as the landing point, noting the audience should be small enough during beta to avoid overwhelming the list.

Jelte responds pragmatically: start with pgsql-hackers since it's low-friction for reporters, and change the approach later if it becomes too noisy. He notes the alternative (wiki-based tracking) is hampered by the difficulty of getting wiki edit permissions.

Significance

This reverses Jacob's earlier position (noted in Prior Analysis #1) where he had removed a call-to-action for failure reports, concluding it would create more noise than signal. Now both participants agree that structured reporting to pgsql-hackers is worthwhile — the [grease] tag provides filterability, and the beta-only scope limits volume.

The practical outcome is that the locked wiki page will be updated to include reporting instructions directing users to pgsql-hackers.

History (2 prior analyses)
2026-06-01 · claude-opus-4-6

Protocol Greasing During PostgreSQL 19 Beta — May 2026 Summary

Overview

Jacob Champion announced plans to exercise PostgreSQL's wire-protocol negotiation machinery during the 19 beta cycle using GREASE (Generate Random Extensions And Sustain Extensibility), a technique borrowed from TLS 1.3 and formalized in IETF drafts. The goal is to flush out ossification bugs in middleboxes, connection poolers, and alternative server/client implementations before PostgreSQL ever ships a real protocol change.

Technical Approach

PostgreSQL's frontend/backend protocol has been at version 3.0 since 2003. Despite having negotiation machinery (NegotiateProtocolVersion message, _pq_.* parameter namespace), these code paths have never been exercised in production, creating a classic ossification hazard.

The greasing strategy inverts Postel's Law:

  • libpq sends a bogus minor protocol version and at least one bogus _pq_.* extension parameter on every connection
  • libpq strictly validates that the server responds with a correct NegotiateProtocolVersion message identifying the unsupported bits
  • Connections fail-closed if the peer mishandles the grease values

Lifecycle constraints:

  • Grease is committed early in 19 beta, then reverted mid-beta (tracked as an Open Item)
  • PostgreSQL 19 GA will not grease
  • Escape hatch: max_protocol_version=3.0 disables greasing per-connection

Documentation and Communication

Significant discussion focused on where to direct users who hit grease-induced failures:

  • Official docs (libpq-connect.html#LIBPQ-CONNECT-MAX-PROTOCOL-VERSION) are too constrained and permanent for ephemeral beta-only content
  • Wiki page (wiki.postgresql.org/wiki/Grease) chosen as the landing page — allows conversational FAQ tone, fast iteration, and natural post-beta archival
  • Wiki lockdown needed since the URL will appear in libpq error messages; the wiki's coarse-grained locking mechanism (admin-only unlock) is workable but requires coordination
  • Jacob initially considered soliciting failure reports on the wiki page but removed the call to action, concluding it would create more noise than signal without a clear triage process

Attribution

Jelte Fennema-Nio is revealed as the patch author of the greasing feature (consistent with his prior work on protocol extensibility infrastructure). Jacob Champion drove the thread advocacy and communication planning.

Strategic Significance

This establishes PostgreSQL's adoption of modern IETF-style protocol hygiene. A successful grease campaign is effectively a precondition for any future protocol 3.x or 4.0 work — it measures ecosystem readiness and forces broken implementations to surface early rather than blocking real feature deployment later.

2026-06-01 · claude-opus-4-6

No substantive technical progress

The single new message from Jacob Champion is a brief status update confirming that:

  1. Joe Conway locked down the wiki page (as referenced by the linked message).
  2. Jacob has pushed the commit that makes libpq's error path link to the locked wiki page.
  3. The greasing infrastructure is now fully deployed and active — "Now we get to see if anything happens."

There are no new technical arguments, no patch changes, no design discussions, and no position shifts. This is purely a logistical closure message confirming the wiki-lockdown action item (previously identified as a blocker) has been completed and the feature is live in the beta builds.