PostgreSQL

These views failed to hide statistics for expressions that involve columns the accessing user does not have permission to read. View columns such as most_common_vals might expose security-relevant data. The potential interactions here are not fully clear, so in the interest of erring on the side of safety, make rows in these views visible only to the owner of the associated table.

The PostgreSQL Project thanks Lukas Fittl for reporting this problem. (CVE-2024-4317)

By itself, this fix will only fix the behavior in newly initdb’d database clusters. If you wish to apply this change in an existing cluster, you will need to do the following:

Such cases would either fail with surprising complaints about mismatched datatypes, or insert unexpected coercions that could lead to odd results.

SELECT privilege would be required in all practical cases anyway, but require it even if the query reads no columns of the target table. This avoids an edge case in which MERGE would require no privileges whatever, which seems undesirable even when it’s a do-nothing command.

Throw an error if a target row joins to more than one source row, as required by the SQL standard. (The previous coding could silently ignore this condition if a concurrent update was involved.) Also, throw a non-misleading error if a target row is already updated by a later command in the current transaction, thanks to a BEFORE trigger or a volatile function used in the query.

A NULL value satisfies a clause such as `boolcol+ IS NOT FALSE+`, so pruning away a partition containing NULLs yielded incorrect answers.

Moving a regular table to a new schema causes any sequences owned by the table to be moved to that schema too (along with indexes and constraints). This was overlooked for foreign tables, however.

CREATE UNLOGGED TABLE will make any owned sequences be unlogged too. ALTER TABLE missed that consideration, so that an added identity column would have a logged sequence, which seems pointless.

Previously, heap pages that contain no visible tuples were not counted; but it seems more consistent to count all pages returned by the bitmap index scan.

EXPLAIN would sometimes fail to properly display subplan Params referencing variables in other parts of the plan tree.

If the session that creates a temporary table crashes without removing the table, autovacuum will eventually try to remove the orphaned table. However, an incoming session that’s been assigned the same temporary namespace will do that too. If a temporary table has a dependency (such as an owned sequence) then a deadlock could result between these two cleanup attempts.

Due to an oversight, this mode caused all heap pages to be dirtied, resulting in excess I/O. Also, visibility map bits that were incorrectly set would not get cleared.

VACUUM’s computation of per-database frozen-XID values from per-relation values could get confused by a concurrent update of those values by another `VACUUM.

Buffer accesses performed by parallel workers were not getting counted in the statistics reported in VERBOSE mode.

In versions before PostgreSQL 16, it was possible for generated conditions to be evaluated below outer joins when they should be evaluated above (after) the outer join, leading to incorrect query results. All versions have a similar hazard when considering joins to UNION ALL trees that have constant outputs for the join column in some SELECT arms.

This is similar to a fix applied in 16.1, but it solves the problem for parallel plans.

Disable “[.quote]#run condition”# optimization of ntile() and count() with non-constant arguments. This avoids possible misbehavior with sub-selects, typically leading to errors like “[.quote]#WindowFunc not found in subplan target lists”#.

When a plain aggregate is used as a window function, and the window frame start is specified as UNBOUNDED PRECEDING, the frame’s head cannot move so we do not need to use the special (and more expensive) moving-aggregate mode. This optimization was intended all along, but due to a coding error it never triggered.

This would typically end in a crash or unexpected error message.

In production builds this error frequently didn’t cause any problems, as the freed data would most likely not get overwritten before it was used.

This change solves performance problems that were reported for certain operations in installations with many thousands of roles.

The output columns of such a function call must be defined by an AS clause that specifies the column names and data types. If the actual function output value doesn’t match that, an error is supposed to be thrown at runtime. However, some code paths would examine the actual value prematurely, and potentially issue strange errors or suffer assertion failures if it doesn’t match expectations.

A procedure implemented in SQL language that returns a single composite-type column would cause an assertion failure or core dump.

In the case where the source timestamp is before the origin timestamp and their difference is already an exact multiple of the stride, the code incorrectly subtracted the stride anyway. Also, detect some integer-overflow cases that would have produced incorrect results.

Some cases that should cause an out-of-range error produced an incorrect result instead.

If the relation referenced by the argument is dropped concurrently, the function’s intention is to return NULL, but sometimes it failed instead.

Transaction IDs more than 2³¹ transactions in the past could be misidentified as recent, leading to misbehavior of pg_xact_status() or txid_status().

Because the freespace map isn’t WAL-logged, this was possible in edge cases involving an OS crash, a replica promote, or a PITR restore. The result would be a “[.quote]#could not read block”# error.

Previously this was just an assertion check, but promote it into a regular runtime error. This will provide a more on-point error message when reindexing a user-defined index expression that attempts to access its own table.

The value physically stored in the index is truncated, and previously a pointer to that value was returned to callers. This provoked complaints when testing under valgrind. In theory it could result in crashes, though none have been reported.

An invalidation event arriving while a subscriber identifies which tables need to be synced would be forgotten about, so that any tables newly in need of syncing might not get processed in a timely fashion.

It was once theoretically possible for us to operate with a socket that’s in blocking mode; but that hasn’t worked fully in a long time, so fail at connection start rather than misbehave later.

System-reported errors passed through by OpenSSL were reported with a numeric error code rather than anything readable.

A multi-threaded libpq client program could get an incorrect or corrupted error message after a network lookup failure.

Although GNU gettext’s implementation seems to be fine with concurrent calls, the version available on Windows is not.

The server treats parameter names case-insensitively, so this code should too. This avoids putting redundant entries into the generated postgresql.conf file.

This happened only when cancelling a non-last query in a query string made with \; separators.

This avoids problems on macOS, where the Finder may create such files.

This mistake caused parse errors if such a comment followed a WHEN expression in a PL/pgSQL CASE statement.

A variable-length datum in a heap tuple or index tuple could have either a short or a long header, depending on compression parameters that applied when it was made. Treat these cases as equivalent rather than complaining if there’s a difference.

These output functions are only used for displaying index entries in contrib/pageinspect, so the errors are of limited practical concern.

This could occur in cases involving UNION ALL with constant-emitting subqueries. Sorting by a constant is useless of course, but it also risks being misinterpreted by the remote server, leading to “[.quote]#ORDER BY position `N` is not in select list”# errors.

This should have the same results for practical purposes. However, GMT is recognized by hard-wired code in the server, while UTC is looked up in the timezone database. So the old code could fail in the unlikely event that the remote server’s timezone database is missing entries.