Hi,Please see attached draft of the 2026-08-13 release announcement, which includes fixes both for the quarterly update release and the PG19 Beta. Please check for accuracy, glaring omissions, confusing phrases, and typos.
I'll note that this was particularly interesting to pull together given the number of fixes in this release, which was the most I've ever seen (and by far). I tried to keep the list in its usual 20-25 range (and keep in mind, the full list is available in the release notes) along with my usual attempts to explain the fixes to a general audience, but this was definitely a more challenging announcement to write up.
This is also to say a thanks to everyone for working to pull together this update release!
Jonathan
The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 18.5, 17.11, 16.15, 15.19, and 14.24, as well as the third beta release of PostgreSQL 19. This release fixes over 110 bugs reported over the last several months. There are three issues that may require you to take extra steps after updating, which are described in detail below. These issues are related to: * Parallel GIN index builds * [`btree_gist`](https://www.postgresql.org/docs/current/btree-gist.html) * [`ltree`](https://www.postgresql.org/docs/current/ltree.html) For the full list of changes, please review the [release notes](https://www.postgresql.org/docs/release/). PostgreSQL 14 EOL Notice ------------------------ PostgreSQL 14 will stop receiving fixes on November 12, 2026. If you are running PostgreSQL 14 in a production environment, we suggest that you make plans to upgrade to a newer, supported version of PostgreSQL. Please see our [versioning policy](https://www.postgresql.org/support/versioning/) for more information. Bug Fixes and Improvements -------------------------- This update fixes over 110 bugs that were reported in the last several months. The issues listed below affect PostgreSQL 18. Some of these issues may also affect other supported versions of PostgreSQL. * Fix parallel [GIN](https://www.postgresql.org/docs/current/gin.html) index builds to correctly update the table's `reltuples` value in `pg_class`. Previously, a parallel worker could report an uninitialized row count, leaving `reltuples` set to a bogus value (including `Infinity` or `NaN`). Such a value can cause autovacuum and autoanalyze to not process the table, and this situation will not self-correct. If you have any tables with GIN indexes, we recommend checking that their `reltuples` values look reasonable after updating. See the "Updating" section for how to identify and repair affected tables. * Several fixes to [`btree_gist`](https://www.postgresql.org/docs/current/btree-gist.html), including for `NaN` handling for `float4`/`float8` that could give wrong answers for columns containing `NaN` and correct sorting of `bit`/`bit varying` values during index building. You may need to reindex `btree_gist` indexes on `float` or `bit` columns after updating. See the "Updating" section. * Fix an integer overflow in [`ltree`](https://www.postgresql.org/docs/current/ltree.html) comparisons. `ltree` values containing more than about 14,653 labels could compare incorrectly, which could present as a corrupt B-tree index. If you use `ltree`, you may need to reindex affected indexes after updating. See the "Updating" section. * Fix a self-deadlock that could occur while replaying WAL generated by an older minor version. This regression, introduced in the previous set of minor releases, could cause a standby server following a primary running an older minor version to become stuck. * Fix [partition pruning](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) for `RANGE`-partitioned tables so the `DEFAULT` partition is no longer skipped in cases where it should be scanned. Previously this could cause rows to be missing from query results. * Several fixes for partitioned tables that have foreign-table partitions, including when run-time partition pruning determined that some partitions don't need to be scanned, in-flight requests to foreign servers were not always handled correctly, leading to failures. * Several fixes to [`RETURNING`](https://www.postgresql.org/docs/current/dml-returning.html) with `OLD` and `NEW`. * Improve hash join performance when there are multiple join keys and many `NULL` values. * Several fixes to the planner that could produce wrong query results, including `value IN (array)` tests where the array might be empty, and `COUNT()` window functions that use an `EXCLUDE` clause or lack `ORDER BY`. * Add missing checks for the hashability of equality comparisons on container types ([arrays](https://www.postgresql.org/docs/current/arrays.html), [composite types](https://www.postgresql.org/docs/current/rowtypes.html), and [ranges](https://www.postgresql.org/docs/current/rangetypes.html)). Without these checks, the planner could choose a hash-based plan that then failed at execution with a "could not identify a hash function" error. * Fix attaching partitions of indexes that are [exclusion constraints](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-EXCLUSION), which also fixes dump/restore of partitioned exclusion constraints. * Fix [`REINDEX CONCURRENTLY`](https://www.postgresql.org/docs/current/sql-reindex.html) on an index backing a deferred uniqueness constraint, which could cause false constraint-violation reports. * Restore an index-scan optimization that converts a [`LIKE`](https://www.postgresql.org/docs/current/functions-matching.html) or regular-expression exact-match pattern into an equality index condition when the index and expression collations differ. * Several fixes to [`jsonpath`](https://www.postgresql.org/docs/current/functions-json.html#FUNCTIONS-SQLJSON-PATH), including that the `@?` and `@@` operators now correctly raise an error for an undefined variable in the path expression. Previously, because these operators cannot supply variable values, an undefined variable was treated as a JSON `null` rather than an error, which could also lead to unbounded memory consumption. * Ensure access is blocked to other sessions' temporary tables, which could lead to silently incorrect results. * Fix `"no empty local buffer available"` errors during temporary table access when a large [`effective_io_concurrency`](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY) setting could allow a single read stream to consume all local buffers. * Prevent [autovacuum](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM) from processing databases in the wrong order (lowest-priority first instead of highest). * Restore [`VACUUM`](https://www.postgresql.org/docs/current/sql-vacuum.html)'s wraparound failsafe mode to use the full shared buffer pool as intended, which had slowed down emergency vacuuming. * Fix possible incorrect decoding of index tuples during GiST and SP-GiST [index-only scans](https://www.postgresql.org/docs/current/indexes-index-only-scans.html), which could emit corrupted data. * Fix a race condition in conflict detection under [`SERIALIZABLE`](https://www.postgresql.org/docs/current/transaction-iso.html#XACT-SERIALIZABLE) isolation. A conflict could be missed when examining an initially-empty btree index, allowing conflicting transactions to commit and breaking serializability. * Fix WAL logging of operations that clear bits in table [visibility maps](https://www.postgresql.org/docs/current/storage-vm.html). This could lead to producing incorrect incremental backups or potentially leaving torn-page writes uncorrected. * Fix [logical decoding](https://www.postgresql.org/docs/current/logicaldecoding.html) of empty prepared transactions. A prepared transaction with no decodable changes could send `COMMIT PREPARED` or `ROLLBACK PREPARED` to the output plugin with no preceding `PREPARE`, which breaks replication for the built-in subscriber. * Several fixes to [`libpq`](https://www.postgresql.org/docs/current/libpq.html), including ensuring it drains all pending bytes from the SSL or GSS decryption buffer when reading data, avoiding cases where a client waits for data that has already arrived. * Fix [`pg_createsubscriber`](https://www.postgresql.org/docs/current/app-pgcreatesubscriber.html) to clean up objects left on a publisher after failure, including a replication slot. * Fix [`pg_restore`](https://www.postgresql.org/docs/current/app-pgrestore.html) with `--statistics` or `--statistics-only` so that, when combined with other selective-restore options such as `--schema`, it restores the expected items, matching the behavior of `pg_dump`. This release also updates time zone data files to tzdata release 2026c, in which Alberta (America/Edmonton) will be on year-round UTC-06 (effectively, permanent DST) beginning in November 2026. This release assumes that their TZ abbreviation will be CST from that time forward (though this could change). It also reflects that Morocco (Africa/Casablanca) will move to permanent UTC+00, without daylight saving transitions, on September 20, 2026. Updating -------- All PostgreSQL update releases are cumulative. As with other minor releases, users are not required to dump and reload their database or use `pg_upgrade` in order to apply this update release; you may simply stop PostgreSQL and update its binaries. If you have any tables with GIN indexes, we recommend checking their `reltuples` values after updating. A prior bug in parallel GIN index builds could have left `reltuples` set to a bogus value (including `Infinity` or `NaN`) that prevents autovacuum and autoanalyze from ever processing the table. The following query lists the tables that have a GIN index, along with their current `reltuples`: ``` SELECT DISTINCT t.oid::regclass, t.reltuples FROM pg_class t JOIN pg_index i ON t.oid = i.indrelid JOIN pg_class ic ON i.indexrelid = ic.oid WHERE t.relhasindex AND ic.relam = 2742; ``` For any table whose `reltuples` value looks incorrect, run [`ANALYZE`](https://www.postgresql.org/docs/current/sql-analyze.html) on it (or create another index) to reset the value. If you use `btree_gist`, you should reindex `btree_gist` indexes on `float4` or `float8` columns that might contain `NaN` values, as well as `btree_gist` indexes on `bit` or `bit varying` columns, for example: ``` REINDEX INDEX your_index_name; ``` If you use `ltree` and have btree indexes over `ltree` values with very many labels (more than about 14,653), you should [reindex](https://www.postgresql.org/docs/current/sql-reindex.html) those indexes, since they may be corrupt, for example: ``` REINDEX INDEX your_index_name; ``` Users who have skipped one or more update releases may need to run additional post-update steps; please see the release notes from earlier versions for details. For more details, please see the [release notes](https://www.postgresql.org/docs/release/). A Note on the PostgreSQL 19 Beta -------------------------------- This release marks the third beta release of PostgreSQL 19 and puts the community one step closer to general availability tentatively around September/October 2026. In the spirit of the open source PostgreSQL community, we strongly encourage you to test the new features of PostgreSQL 19 on your systems to help us eliminate bugs and other issues. While we do not advise you to run PostgreSQL 19 Beta 3 in production environments, we encourage you to find ways to run your typical application workloads against this beta release. Your testing and feedback helps the community ensure that PostgreSQL 19 upholds our standards of delivering a stable, reliable release of the world's most advanced open source relational database. Please read more about our [beta testing process](https://www.postgresql.org/developer/beta/) and how you can contribute: [https://www.postgresql.org/developer/beta/](https://www.postgresql.org/developer/beta/) Upgrading to PostgreSQL 19 Beta 3 --------------------------------- To upgrade to PostgreSQL 19 Beta 3 from an earlier version of PostgreSQL, you will need to use a strategy similar to upgrading between major versions of PostgreSQL (e.g. `pg_upgrade` or `pg_dump` / `pg_restore`). For more information, please visit the documentation section on [upgrading](https://www.postgresql.org/docs/19/static/upgrading.html). Changes Since Beta 2 -------------------- Fixes and changes in PostgreSQL 19 Beta 3 include: * Revert `GROUP BY ALL`. * Several fixes for the new `FOR PORTION OF` temporal table syntax. * Several fixes for the new logical replication sequence synchronization feature, including a race involving `REFRESH SEQUENCES`. * Fix an "unexpected logical decoding status change" error that could occur when logical decoding is activated concurrently. * Fix issues around ownership changes for subscriptions. * Fix wrong query results from `postgres_fdw` when pushing down an array comparison such as `field = ANY($1)` that involves an implicit type coercion. * Fix a crash during foreign-key checks involving a nullable `UNIQUE` constraint. * Fix `pg_plan_advice` parsing of underscores in numeric literals. * Fix a missing `FORMAT` clause when deparsing `JSON_ARRAY(query)`. Please see the [release notes](https://www.postgresql.org/docs/19/release-19.html) for a complete list of new and changed features: [https://www.postgresql.org/docs/19/release-19.html](https://www.postgresql.org/docs/19/release-19.html) Testing for Bugs & Compatibility -------------------------------- The stability of each PostgreSQL release greatly depends on you, the community, to test the upcoming version with your workloads and testing tools to find bugs and regressions before the general availability of PostgreSQL 19. As this is a Beta, minor changes to database behaviors, feature details, and APIs are still possible. Your feedback and testing will help determine the final tweaks on the new features, so please test in the near future. The quality of user testing helps determine when we can make a final release. A list of [open issues](https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items) is publicly available in the PostgreSQL wiki. You can [report bugs](https://www.postgresql.org/account/submitbug/) using this form on the PostgreSQL website: [https://www.postgresql.org/account/submitbug/](https://www.postgresql.org/account/submitbug/) Beta Schedule ------------- This is the third beta release of version 19. The PostgreSQL Project will release one or more release candidates, before the final release around September/October 2026. For further information please see the [Beta Testing](https://www.postgresql.org/developer/beta/) page. Links ----- * [Download](https://www.postgresql.org/download/) * [Release Notes](https://www.postgresql.org/docs/release/) * [Security](https://www.postgresql.org/support/security/) * [Versioning Policy](https://www.postgresql.org/support/versioning/) * [Beta Testing Information](https://www.postgresql.org/developer/beta/) * [PostgreSQL 19 Beta Release Notes](https://www.postgresql.org/docs/19/release-19.html) * [PostgreSQL 19 Open Issues](https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items) * [Submit a Bug](https://www.postgresql.org/account/submitbug/) * [Donate](https://www.postgresql.org/about/donate/) If you have corrections or suggestions for this release announcement, please send them to the [email protected]_ public [mailing list](https://www.postgresql.org/list/).
OpenPGP_signature.asc
Description: OpenPGP digital signature
