PostgreSQL

This error led to a text-type value being interpreted as an unknown-type value (that is, a zero-terminated string) at runtime. This could result in disclosure of server memory following the text value.

The PostgreSQL Project thanks Jingzhou Fu for reporting this problem. (CVE-2023-5868)

When assigning new elements to array subscripts that are outside the current array bounds, an undetected integer overflow could occur in edge cases. Memory stomps that are potentially exploitable for arbitrary code execution are possible, and so is disclosure of server memory.

The PostgreSQL Project thanks Pedro Gallegos for reporting this problem. (CVE-2023-5869)

The documentation says that pg_signal_backend cannot issue signals to superuser-owned processes. It was able to signal these background processes, though, because they advertise a role OID of zero. Treat that as indicating superuser ownership. The security implications of cancelling one of these process types are fairly small so far as the core code goes (we’ll just start another one), but extensions might add background workers that are more vulnerable.

Also ensure that the is_superuser parameter is set correctly in such processes. No specific security consequences are known for that oversight, but it might be significant for some extensions.

The PostgreSQL Project thanks Hemanth Sandrana and Mahendrakar Srinivasarao for reporting this problem. (CVE-2023-5870)

Fix a case where the location of a page downlink was incorrectly tracked, and introduce some logic to allow recovering from such situations rather than silently doing the wrong thing. This error could result in incorrect answers from subsequent index searches. It may be advisable to reindex all GiST indexes after installing this update.

There are interval values that are distinguishable but compare equal, for example 24:00:00 and 1 day. This breaks assumptions made by btree de-duplication, so interval columns need to be excluded from de-duplication. This oversight can cause incorrect results from index-only scans. Moreover, after updating amcheck will report an error for almost all such indexes. Users should reindex any btree indexes on interval columns.

The distance calculation for dates was backward, causing poor decisions about which entries to merge. The index still produces correct results, but is much less efficient than it should be. Reindexing BRIN minmax_multi indexes on date columns is advisable.

Infinities were mistakenly treated as having distance zero rather than a large distance from other values, causing poor decisions about which entries to merge. Also, finite-but-very-large values (near the endpoints of the representable timestamp range) could result in internal overflows, again causing poor decisions. The index still produces correct results, but is much less efficient than it should be. Reindexing BRIN minmax_multi indexes on timestamp and timestamptz columns is advisable if the column contains, or has contained, infinities or large finite values.

This bug might have caused unexpected failures while trying to insert large interval values into such an index.

Some cases involving an IS NULL condition on one of the partition keys could result in a crash.

If the initially-named table is excluded by constraints, but not all its inheritance descendants are, the first non-excluded descendant was identified as the primary target table. This would lead to firing statement-level triggers associated with that table, rather than the initially-named table as should happen. In v16, the same oversight could also lead to “[.quote]#invalid perminfoindex 0 in RTE with relid NNNN”# errors.

When restoring an indexscan to a previously marked position, the code could miss required setup steps if the scan had advanced exactly to the end of the matches for a ScalarArrayOpExpr (that is, an indexcol = ANY(ARRAY[])) clause. This could result in missing some rows that should have been fetched.

Previously, a not-on-point complaint “[.quote]#only heap AM is supported”# would be raised.

Report an error if pgstatindex(), pgstatginindex(), pgstathashindex(), or pgstattuple() is applied to an invalid index. If brin_desummarize_range(), brin_summarize_new_values(), brin_summarize_range(), or gin_clean_pending_list() is applied to an invalid index, do nothing except to report a debug-level message. Formerly these functions attempted to process the index, and might fail in strange ways depending on what the failed CREATE INDEX had left behind.

If the incoming vector includes position data, the binary receive function left wasted space (roughly equal to the size of the position data) in the finished tsvector. In extreme cases this could lead to “[.quote]#maximum total lexeme length exceeded”# failures for vectors that were under the length limit when emitted. In any case it could lead to wasted space on-disk.

This could lead to poor page-split decisions in GiST indexes on tsvector columns.

Instead of propagating the current transaction’s properties to the new transaction, they propagated some previous transaction’s properties.

Recent refactoring accidentally removed the intended error check for this, such that it ended in “[.quote]#cache lookup failed for function 0”# instead of a useful error message.

No built-in parameter fits this description, but an extension could define such a parameter.

This prevents possible misbehavior if any catalog entries for the temp tables have fields wide enough to require toasting (such as a very complex CHECK condition).

This fix avoids a race condition in which a child process that has been forked off by system(), but hasn’t yet exec’d the intended child program, might receive and act on a signal intended for the parent server process. That would lead to duplicate cleanup actions being performed, which will not end well.

On some file systems, reading pg_control may not be an atomic action when the server concurrently writes that file. This is detectable via a bad CRC. Retry a few times to see if the file becomes valid before we report error.

Acquire the appropriate lock before reading pg_control, to ensure we get a consistent view of that file.

On 64-bit machines we will allow values of track_activity_query_size large enough to cause 32-bit overflow when multiplied by the allowed number of connections. The code actually allocating the per-backend local array was careless about this though, and allocated the array incorrectly.

The block-level counters should be reset to zero at the same time we update the current-relation field.

DDL commands, such as replacement of a function that has been inlined into a CALL argument, can create the need to re-plan a CALL that has been cached by PL/pgSQL. That was not happening, leading to misbehavior or strange errors such as “[.quote]#cache lookup failed”#.

This oversight could lead to assertion failures, core dumps, or “[.quote]#bogus varno”# errors.

In most cases this oversight was harmless, since these functions would be unlikely to disappear while the node’s original operator remains present.

An out-of-memory error occurring at just the wrong point could leave behind inconsistent state that would lead to an infinite loop.

Previously this would be treated as a bogus-data condition, leading to the conclusion that we’d reached the end of WAL, which is incorrect and could lead to inconsistent WAL replay.

Integer overflow was possible on platforms where long is wider than int, although it would take a multiple-terabyte temporary file to cause a problem.

Aside from saving a few cycles, this prevents failure after a cache invalidation for statements that must not set a snapshot, such as SET TRANSACTION ISOLATION LEVEL.

This avoids possible use of dangling pointers when a tuple slot outlives the tuple descriptor with which its value was constructed.

This ensures that after renaming a role, the meaning of the special string $user is re-determined.

This code violated the conditions required for crash safety by writing WAL before marking changed buffers dirty. No core code uses this function, but extensions do (contrib/bloom does, for example).

Formerly, only the table-level ACL would get restored if both types were present.

These obsolete data types were removed in PostgreSQL version 12, so check to make sure they aren’t present in an older database before claiming it can be upgraded.

This has only been seen to occur when the server connection runs through pgbouncer.

This fix prevents false-positive reports of “[.quote]#the first child of leftmost target page is not leftmost of its level”, [.quote]“block NNNN is not leftmost”# or “[.quote]#left link/right link pair in index XXXX not in agreement”#. They appeared if amcheck ran after an unfinished btree index page deletion and before VACUUM had cleaned things up.

Such an indexscan failed to return all the entries it should.

Xcode 15 (released with macOS Sonoma) changed the linker’s behavior in a way that causes many duplicate-library warnings while building PostgreSQL. These were harmless, but they’re annoying so avoid citing the same libraries twice. Also remove use of the -multiply_defined suppress linker switch, which apparently has been a no-op for a long time, and is now actively complained of.

Presence of this abbreviation in the default list can cause failures on recent Debian and Ubuntu releases, as they no longer install the underlying tzdb entry by default. Since this is a made-up abbreviation for a zone with a total human population of about two dozen, it seems unlikely that anyone will miss it. If someone does, they can put it back via a custom abbreviations file.