PostgreSQL 19 Beta 1 release announcement draft

First seen: 2026-05-29 03:23:08+00:00 · Messages: 13 · Participants: 7

Latest Update

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

Incremental Update: PostgreSQL 19 Beta 1 Announcement Draft (Round 2)

Summary of New Developments

The thread progressed with several new feature inclusion requests, a terminology correction, and Jonathan Katz incorporating feedback into a revised draft. Three new participants contributed substantive suggestions.

New Feature Inclusion Requests

REPACK CONCURRENTLY — Naming Clarification

Álvaro Herrera pointed out a factual error in the draft: there is no "REPACK CONCURRENTLY" command as a standalone entity. PostgreSQL 19 added an ALTER TABLE ... REPACK command with a CONCURRENTLY option (specified in parentheses). The draft apparently listed these as two separate commands, which misrepresents the feature's structure. This is a correctness issue in the announcement rather than a feature promotion request.

LISTEN/NOTIFY Scalability — Proposed Addition

Joel Jacobson advocated for including LISTEN/NOTIFY scalability improvements in the Performance section. His argument is backed by external visibility data: the "Postgres LISTEN/NOTIFY does not scale" blog post from recall.ai was the #3 most popular Postgres-related story on Hacker News in the past year. The fix was directly motivated by this public criticism. Jonathan Katz accepted the suggestion, proposing the phrasing: "There are also improvements for LISTEN/NOTIFY scalability that impact multi-channel workloads." Joel approved this wording.

This is technically interesting because LISTEN/NOTIFY scalability is a known pain point for applications using PostgreSQL as a message/event bus (common in real-time applications, job queues, and change-data-capture patterns). The fix targets multi-channel workloads specifically, suggesting the optimization addresses contention or scanning overhead that scales with the number of distinct channels.

Protocol Greasing — Testing/Compatibility Section

Jelte Fennema-Nio suggested calling out protocol greasing in the "Testing for Bugs & Compatibility" section. During the beta, libpq will request non-existing protocol versions to ensure third-party middleware and connection poolers don't break when PostgreSQL eventually bumps the default protocol version. This is a proactive compatibility testing mechanism borrowed from TLS/HTTP practices (RFC 8701) — deliberately injecting unknown values to prevent ecosystem ossification. This is particularly relevant for the beta announcement since it may cause unexpected behavior in tools that incorrectly reject unknown protocol versions.

Terminology Fix

Tom Lane flagged that "non-aggregate and non-window parameters" in the GROUP BY ALL description misuses "parameters" — a heavily overloaded term in PostgreSQL (GUC parameters, function parameters, prepared statement parameters). He suggested "output columns" instead. Jonathan Katz accepted immediately.

Revised Draft

Jonathan Katz posted an updated full draft on June 4, incorporating the feedback received. The GROUP BY ALL description, LISTEN/NOTIFY mention, and terminology fix are confirmed included.

History (1 prior analysis)
2026-06-01 · claude-opus-4-6

PostgreSQL 19 Beta 1 Release Announcement Draft Review

Overview

This thread concerns the community review of the PostgreSQL 19 Beta 1 release announcement draft, a standard part of the PostgreSQL release process where the announcement text is circulated for accuracy checking and feedback on feature presentation. The thread reveals interesting insights into which PostgreSQL 19 features the community considers most impactful and how they should be communicated to users.

The Core Task

Release announcements serve dual purposes: they inform existing users about upgrade-worthy features, and they market PostgreSQL to potential adopters. The ordering and framing of features in the announcement is therefore a strategic communication decision, not merely a technical documentation exercise. Jonathan Katz (a PostgreSQL Core Team member and major contributor to release communications) circulated the draft with a tight review window (approximately 6 days).

Key Feature Discussions

pg_plan_advice — Promotion in Announcement Priority

Jakub Wartak's recommendation to elevate pg_plan_advice in the announcement reflects real-world operational pain. This feature (likely providing plan hints or guidance functionality) addresses a long-standing gap in PostgreSQL relative to commercial databases like Oracle and SQL Server. The argument is compelling from both a migration perspective (users refusing to migrate from Oracle due to lack of hint-like functionality) and an operational perspective (emergency situations where query plans go wrong in production).

The fact that this feature exists in PostgreSQL 19 at all represents a significant philosophical shift — PostgreSQL has historically resisted optimizer hints, preferring the optimizer to make correct decisions autonomously. That pg_plan_advice made it into the release suggests the community found an acceptable middle ground, and Wartak's feedback suggests it deserves prominent placement to signal this shift.

64-bit MultiXactOffset

This is a deeply architectural improvement that addresses one of PostgreSQL's most dangerous operational failure modes. The MultiXact system tracks shared row locks (commonly triggered by foreign key checks in concurrent workloads). Prior to this change, the 32-bit MultiXact member offset counter could wrap around, triggering emergency anti-wraparound vacuums that could freeze entire systems.

Wartak's suggested phrasing — emphasizing prevention of "emergency anti-wraparound vacuums previously caused by highly concurrent workloads involving FKs" — correctly identifies the user-facing impact. This is analogous to the earlier expansion of transaction IDs and is part of PostgreSQL's ongoing effort to eliminate wraparound-related failure modes. For high-concurrency OLTP workloads with extensive foreign key relationships, this eliminates a class of production incidents entirely.

GROUP BY ALL

Both reviewers independently suggested adding GROUP BY ALL to the announcement under Developer Experience. This SQL syntactic convenience (automatically grouping by all non-aggregate columns in the SELECT list) is a quality-of-life improvement popular in modern analytical SQL dialects (DuckDB, BigQuery, etc.). Its omission from the draft suggests it may have been considered too minor, but the dual independent recommendations indicate community consensus that it's announcement-worthy.

jsonpath String Functions

Florents Tselai suggested improved phrasing for the jsonpath enhancements, specifically the addition of lower(), upper(), initcap(), replace(), split_part(), and the trim() family. This extends PostgreSQL's JSON processing capabilities, bringing jsonpath closer to feature parity with regular string processing. The suggested phrasing ("extends string processing capabilities in jsonpath") better frames the enhancement as a coherent capability expansion rather than a list of individual functions.

Communication Strategy Observations

The feedback reveals a tension in release announcement drafting:

  1. Operational significance vs. feature novelty: The 64-bit MultiXactOffset change is architecturally significant but may seem dry; proper framing emphasizes the production incidents it prevents.
  2. Migration enablement: pg_plan_advice may be the single most important migration-enabling feature for Oracle/SQL Server shops, warranting prominent placement.
  3. Developer appeal: GROUP BY ALL and jsonpath improvements attract developers from modern data tools ecosystems (DuckDB, etc.).

Process Notes

The review window (May 29 to June 4, 2026) is typical for PostgreSQL beta announcements, giving approximately one week for community feedback before the beta release. The beta release itself triggers a broader testing period where the community validates features before the final release (typically in the fall).