PostgreSQL

The array code previously did not complain about cases where an array’s lower bound plus length overflows an integer. This resulted in later entries in the array becoming inaccessible (since their subscripts could not be written as integers), but more importantly it confused subsequent assignment operations. This could lead to memory overwrites, with ensuing crashes or unwanted data modifications. (CVE-2021-32027)

If the UPDATE list contains any multi-column sub-selects (which give rise to junk columns in addition to the results proper), the UPDATE path would end up storing tuples that include the values of the extra junk columns. That’s fairly harmless in the short run, but if new columns are added to the table then the values would become accessible, possibly leading to malfunctions if they don’t match the datatypes of the added columns.

In addition, in versions supporting cross-partition updates, a cross-partition update triggered by such a case had the reverse problem: the junk columns were removed from the target list, typically causing an immediate crash due to malfunction of the multi-column sub-select mechanism. (CVE-2021-32028)

If an UPDATE for a partitioned table caused a row to be moved to another partition with a physically different row type (for example, one with a different set of dropped columns), computation of RETURNING results for that row could produce errors or wrong answers. No error is observed unless the UPDATE involves other tables being joined to the target table. (CVE-2021-32029)

When applied to a foreign-key constraint of a partitioned table, ALTER TABLE ... ALTER CONSTRAINT failed to adjust the DEFERRABLE and/or INITIALLY DEFERRED markings of the constraints and triggers of leaf partitions. This led to unexpected behavior of such constraints. After updating to this version, any misbehaving partitioned tables can be fixed by executing a new ALTER command to set the desired properties.

This change also disallows applying such an ALTER directly to the constraints of leaf partitions. The only supported case is for the whole partitioning hierarchy to have identical constraint properties, so such `ALTER`s must be applied at the partition root.

GENERATED ... AS IDENTITY implies NOT NULL, so don’t allow it to be combined with an explicit NULL specification.

Previously, over-eager validity checks might reject these commands, even if the values would have worked when used later. This created a command ordering hazard for dump/reload and upgrade scenarios.

Sufficiently deep nesting of WITH constructs (at least seven levels) triggered core dumps or incorrect complaints of faulty WITH nesting.

This led to a parse tree in which the COLLATE appears to be applied to a non-collatable value. While that normally has no real impact (since COLLATE has no effect at runtime), it was possible to construct views that would be rejected during dump/reload.

This could cause crashes in some situations.

Only plain functions are supported here. While trying to call an aggregate function failed already, calling a window function would crash, and calling a procedure would work only if the procedure did no transaction control.

Previously, such cases would usually cause a crash.

This error could cause the quantifier to act non-greedy, that is behave like an {`m,n}?` quantifier would do in full regular expressions.

This led to strange estimates for queries such as SELECT ... GROUP BY a, b, ctid.

This typically led to a NaN selectivity value, causing assertion failures or strange planner behavior.

If the page range size used by a BRIN index isn’t a power of two, there were corner cases in which a bitmap scan could try to fetch pages past the actual end of the table, leading to “[.quote]#could not open file”# errors.

If the number of index matches became large enough to make the bitmap holding them become lossy (a threshold that depends on work_mem), the code could get confused about whether rechecks are required, allowing rows to be returned that don’t actually match the query.

This reverts a change that caused intermittent “[.quote]#could not rename file …​: Permission denied”# log messages. While there were not serious consequences, the log spam was annoying.

This error could lead to subsequent WAL records being written under the wrong timeline ID, leading to consistency problems, or even complete failure to be able to restart the server, later on.

When a standby server is shut down while still in recovery, some locks might be left held. This causes assertion failures in debug builds; it’s unclear whether any serious consequence could occur in production builds.

The core code won’t do this, but a replica trigger could.

FreeBSD 13 supports open_datasync, which would normally become the default choice. However, it’s unclear whether that is actually an improvement for Postgres, so preserve the existing default for now.

The notion of tracking “[.quote]#stale”# index statistics proved to interact badly with the autovacuum_vacuum_insert_threshold parameter, resulting in unnecessary full-index scans and consequent degradation of autovacuum performance. The latter mechanism seems superior, so remove the stale-statistics logic. The control parameter for that, vacuum_cleanup_index_scale_factor, will be removed entirely in v14. In v13, it remains present to avoid breaking existing configuration files, but it no longer does anything.

When updating trigger properties during ALTER CONSTRAINT, the post-alter hook was told that we are updating a trigger, but the constraint’s OID was passed instead of the trigger’s.

This error could result in temporary files not being cleaned up promptly after a parallel query.

This error was harmless on most platforms, but could cause issues on platforms lacking atomic variables and/or spinlock support.

Previously, such cases led to errors about leaked tuple descriptors.

A previous bug fix caused environment variables (such as PGPORT) to override entries in the service file in this context. Restore the previous behavior, in which the priority is the other way around.

Previously, this case failed with “[.quote]#savepoint "pg_psql_temporary_savepoint" does not exist”#.

A very fast typist could fool the code’s file-timestamp-based detection of whether the temporary edit file was changed.

A fix introduced in the previous minor release should not be applied to partitioned tables, only traditionally-inherited tables.

When reading a custom-format archive from a non-seekable source, pg_restore neglected to check the archive version. If it was fed a newer archive version than it can support, it would fail messily later on.

Fix detection of some cases where a non-upgradable data type is embedded within a container type (such as an array or range). Also disallow upgrading when user tables contain columns of system-defined composite types, since those types' OIDs are not stable across versions.

This is a valid state after SELECT FOR UPDATE.