PostgreSQL 17 Beta 2 tests the semantics behind new capabilities
The second PostgreSQL 17 beta fixes SQL/JSON defaults, logical decoding resource ownership and vacuum internals. Those changes show where realistic compatibility testing can contribute.
New SQL syntax needs correct behavior when an option is omitted, not only when every clause appears in an example. The June 27 release of PostgreSQL 17 Beta 2 includes a correction to the default behavior of ON EMPTY in SQL/JSON queries. That small entry describes a substantive compatibility concern for applications that depend on implicit behavior.
The release also fixes resource ownership around pg_logical_slot_get_changes and several issues in the new data structure used for vacuum-related data. These are corrections within a preview release. PostgreSQL asks users to run typical application workloads against the beta and explicitly advises against production use. As of this announcement, details of behavior and interfaces can still change.
I value PostgreSQL's predictable behavior more than a long list of additions. Beta testing is useful when it establishes that a new capability fits the behavior an application expects. The second beta's fixes give specific subjects for that work, particularly around defaults and operations whose internal state persists beyond one simple query.
Omitted options are part of the interface
The SQL/JSON fix concerns the default ON EMPTY behavior when a query does not include that clause. An explicit clause and an omitted clause are two different inputs to the implementation. A demonstration that always states the desired behavior cannot establish that the omitted form selects the correct default. Applications that rely on that default exercise a separate path.
The first beta announcement introduced SQL/JSON additions including JSON_TABLE and the query functions JSON_EXISTS, JSON_QUERY and JSON_VALUE. It also explained that the SQL/JSON work had originally been planned for PostgreSQL 15 and reverted during that beta because of design considerations. The history makes review of semantics particularly relevant to this preview.
That earlier reversal does not establish a prediction about the current release. It does explain why the project asks for feedback while behavior can still change. A new function's name is only part of its interface. Missing data and implicit choices also determine what a calling application receives, and a beta offers an opportunity to evaluate those cases before relying on them in production.
For compatibility work, expected outcomes should distinguish an absent value from whatever other inputs the application handles. Beta 2's announcement identifies the default correction without documenting every SQL/JSON rule in the notice itself. The defensible conclusion is that the omitted-clause behavior changed to enforce the intended default. It would be premature to infer an unrelated change to every JSON operation.
Internal ownership matters to externally useful operations
The logical decoding entry names pg_logical_slot_get_changes and resource ownership. That identifies a particular operation, but the announcement does not describe a general loss-of-data incident or provide an affected-workload count. A precise account should retain that scope. An ownership correction in a decoding path is worth exercising without turning it into an unsupported claim about replication as a whole.
PostgreSQL 17's earlier preview includes several broader logical replication changes. The first beta announcement describes failover control and retaining logical replication slots when upgrading from PostgreSQL 17 to a newer version with pg_upgrade. Those are separate capabilities from the resource-ownership fix. A test of slot retention during an upgrade would not automatically test the SQL decoding function named in Beta 2.
The same distinction applies to vacuum. Beta 1 describes a new internal structure intended to reduce memory use. Beta 2 reports several fixes around that structure. A change to internal representation can preserve the operation's purpose while requiring additional correctness work. The maintenance workload is therefore relevant even when an application's ordinary SQL contains no new syntax.
I find maintenance behavior an essential part of judging a database preview. Query results describe the application's immediate interaction, while vacuum and decoding have their own execution paths. The beta announcement gives reasons to include those operations in a representative environment without assuming that every listed fix affected every installation.
A beta upgrade still needs an upgrade procedure
The Beta 2 notice says that moving from an earlier PostgreSQL version requires a strategy similar to a major-version upgrade. It names pg_upgrade or dump and restore. A beta environment is consequently not described as an interchangeable collection of server binaries over one unchanged data directory. Preparing the environment is part of evaluating the release.
That procedure also affects how to interpret a result from Beta 1. A previously successful run establishes behavior for that earlier preview. Repeating the relevant workload on Beta 2 determines whether the revised implementation still matches the application's expectations. The useful evidence is the observed input and output on the version under consideration.
The project expects further betas as required, followed by release candidates. Its stated target is a final release around September or October 2024, subject to testing. On June 27, that remains a schedule expectation. The immediate contribution is to exercise actual application and maintenance behavior against Beta 2 and report reproducible discrepancies while the project can still revise the implementation.