PostgreSQL (64-bit)

What's new in this version:

- This release contains a variety of fixes from 14.3. For information about new features in major release 14, see Section E.5.
- E.1.1. Migration to Version 14.4
- A dump/restore is not required for those running 14.X
- However, if you have any indexes that were created using the CONCURRENTLY option under 14.X, you should re-index them after updating. See the first changelog entry below.
- Also, if you are upgrading from a version earlier than 14.3, see Section E.2.

E.1.2. Changes:
- Prevent possible corruption of indexes created or rebuilt with the CONCURRENTLY option
- An optimization added in v14 caused CREATE INDEX ... CONCURRENTLY and REINDEX ... CONCURRENTLY to sometimes miss indexing rows that were updated during the index build. Revert that optimization. It is recommended that any indexes made with the CONCURRENTLY option be rebuilt after installing this update. (Alternatively, rebuild them without CONCURRENTLY.)
- Harden Memoize plan node against non-deterministic equality functions
- Memoize could crash if a data type's equality or hash functions gave inconsistent results across different calls. Throw a runtime error instead.
- Fix incorrect cost estimates for Memoize plans
- This mistake could lead to Memoize being used when it isn't really the best plan, or to very long executor startup times due to initializing an overly-large hash table for a Memoize node.
- Fix queries in which a “whole-row variable” references the result of a function that returns a domain over composite type
- Fix “variable not found in subplan target list” planner error when pulling up a sub-SELECT that's referenced in a GROUPING function
- Prevent pg_stat_get_subscription() from possibly returning an extra row containing garbage values
- Fix COPY FROM's error checking in the case where the database encoding is SQL_ASCII while the client's encoding is a multi-byte encoding
- This mistake could lead to false complaints of invalidly-encoded input data
- Avoid crashing if too many column aliases are attached to an XMLTABLE or JSON_TABLE construct
- When decompiling a view or rule, show a SELECT output column's AS "?column?" alias clause if it could be referenced elsewhere
- Previously, this auto-generated alias was always hidden; but there are corner cases where doing so results in a non-restorable view or rule definition.
- Report implicitly-created operator families to event triggers
- If CREATE OPERATOR CLASS results in the implicit creation of an operator family, that object was not reported to event triggers that should capture such events
- Fix control file updates made when a restartpoint is running during promotion of a standby server
- Previously, when the restartpoint completed it could incorrectly update the last-checkpoint fields of the control file, potentially leading to PANIC and failure to restart if the server crashes before the next normal checkpoint completes.
- Prevent triggering of standby's wal_receiver_timeout during logical replication of large transactions
- If a large transaction on the primary server sends no data to the standby (perhaps because no table it changes is published), it was possible for the standby to timeout. Fix that by ensuring we send keepalive messages periodically in such situations.
- Prevent open-file leak when reading an invalid timezone abbreviation file
- Such cases could result in harmless warning messages
- Allow custom server parameters to have short descriptions that are NULL
- Previously, although extensions could choose to create such settings, some code paths would crash while processing them
- Remove misguided SSL key file ownership check in libpq
- In the previous minor releases, we copied the server's permission checking rules for SSL private key files into libpq. But we should not have also copied the server's file-ownership check. While that works in normal use-cases, it can result in an unexpected failure for clients running as root, and perhaps in other cases.
- Ensure ecpg reports server connection loss sanely
- Misprocessing of a libpq-generated error result, such as a report of lost connection, would lead to printing “(null)” instead of a useful error message; or in older releases it would lead to a crash
- Prevent crash after server connection loss in pg_amcheck
- Misprocessing of a libpq-generated error result, such as a report of lost connection, would lead to a crash
- Adjust PL/Perl test case so it will work under Perl 5.36
- Avoid incorrectly using an out-of-date libldap_r library when multiple OpenLDAP installations are present while building PostgreSQL