PostgreSQL

One step of a concurrent refresh command was run under weak security restrictions. If a materialized view’s owner could persuade a superuser or other high-privileged user to perform a concurrent refresh on that view, the view’s owner could control code executed with the privileges of the user running REFRESH. Fix things so that all user-determined code is run as the view’s owner, as expected.

The only known exploit for this error does not work in PostgreSQL 16.0 and later, so it may be that v16 is not vulnerable in practice.

The PostgreSQL Project thanks Pedro Gallegos for reporting this problem. (CVE-2024-0985)

There have been multiple reports of backend processes suffering out-of-memory conditions after sufficiently many JIT compilations. This fix should resolve that.

Some uncommon situations involving lateral references could create incorrect plans. Affected queries could produce wrong answers, or odd failures such as “[.quote]#variable not found in subplan target list”#, or executor crashes.

This fixes incorrect results when a subquery is underneath an outer join and has an output column that laterally references something outside the outer join’s scope. The output column might not appear as NULL when it should do so due to the action of the outer join.

This oversight could lead to “[.quote]#WindowFunc not found in subplan target lists”# errors.

This mistake could lead to “[.quote]#cache entry already complete”# errors.

Failure to do this led to errors like “[.quote]#wrong varnullingrels (b) (expected (b 3)) for Var 2/2”#.

When executing a MERGE UPDATE action on a partitioned table, if the UPDATE is turned into a DELETE and INSERT due to changing a partition key column, skip firing AFTER UPDATE ROW triggers, as well as other post-update actions such as RLS checks. These actions would typically fail, which is why a regular UPDATE doesn’t do them in such cases; MERGE shouldn’t either.

If such a trigger attempted to prevent the update by returning NULL, MERGE would suffer an error or assertion failure.

If the tuple being updated had just been updated and moved to another page by another session, there was a narrow window where we would attempt to fetch data from the new tuple version without any pin on its buffer. In principle this could result in garbage data appearing in non-updated columns of the proposed new tuple. The odds of problems in practice seem rather low, however.

The limiting value was too large, allowing “[.quote]#invalid DSA memory alloc request size”# errors to occur with sufficiently large expected hash table sizes.

This mistake could lead to errors such as “[.quote]#attribute 1 of type record has wrong type”#.

This error had no impact in non-assert builds.

This error had no impact in non-assert builds, either.

If a grandchild table would inherit the new column via multiple intermediate parents, the command failed with “[.quote]#tuple already updated by self”#.

Previously this led to a “[.quote]#tuple already updated by self”# failure. Instead, ignore the duplicate.

Failure to acquire the lock could result in “[.quote]#tuple concurrently deleted”# errors if the DROP executes concurrently with ANALYZE.

These places could fail to detect insertion of a volatile function default-argument expression, or decide that a polymorphic function is volatile although it is actually immutable on the datatype of interest. This could lead to improperly rejecting or accepting a GENERATED clause, or to mistakenly applying the constant-default-value optimization in ALTER TABLE ADD COLUMN.

We expand any out-of-line fields in a catalog tuple before inserting it into the catalog caches. That involves database access which might cause invalidation of catalog cache entries — but the new entry isn’t in the cache yet, so we would miss noticing that it should get invalidated. The result is a race condition in which an already-stale cache entry could get made, and then persist indefinitely. This would lead to hard-to-predict misbehavior. Fix by rechecking the tuple’s visibility after detoasting.

Computing 0 - INT64_MIN should result in an overflow error, and did on most platforms. However, platforms with neither integer overflow builtins nor 128-bit integers would fail to spot the overflow, instead returning INT64_MIN.

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

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

With large scram_iterations values, this function could take a long time to run. Allow it to be interrupted by query cancel requests.

In some code paths, it was possible for stale statistics to be returned.

Invalid values were not noted in the view as intended. This escaped detection because there are very few settings in these groups.

Previously we could accept an index that has a different collation from the corresponding element of the partition key, possibly leading to misbehavior.

The code tried to do this with shared rather than exclusive lock on the buffer. This could lead to index corruption if two processes attempted the cleanup concurrently.

If an index root page split occurs concurrently with our own insertion, the code could fail with “[.quote]#buffer NNNN is not owned by resource owner”#.

Trying to use an index of this kind could lead to “[.quote]#No such file or directory”# errors.

Operations on large objects that require ownership privilege failed with “[.quote]#unrecognized class ID: 2613”#, unless run by a superuser.

A no-op ALTER LARGE OBJECT OWNER command (that is, one selecting the existing owner) passed the wrong class ID to the PostAlterHook, probably confusing any extension using that hook.

The numbers labeled as “[.quote]#shared/local”# actually refer only to shared buffers, so change that label to “[.quote]#shared”#.

If an operating system crash occurred during or shortly after CREATE DATABASE, recovery could fail, or subsequent connections to the new database could fail. If a base backup was taken in that window, similar problems could be observed when trying to use the backup. The symptom would be that the database directory, PG_VERSION file, or pg_filenode.map file was missing or empty.

This change provides additional information in the postmaster log that may be useful for diagnosing recovery problems.

The startedInRecovery flag was not correctly set for a subtransaction. This affects only processing of dead index tuples. It could allow a query in a subtransaction to ignore index entries that it should return (if they are already dead on the primary server, but not dead to the standby transaction), or to prematurely mark index entries as dead that are not yet dead on the primary. It is not clear that the latter case has any serious consequences, but it’s not the intended behavior.

Revert a change that made walreceivers non-responsive to SIGTERM while waiting for the replication connection to be established.

This bug appears to be only latent except when running a 32-bit PostgreSQL build on a 64-bit platform.

One edge of the deadlock loop did not involve a lock wait, so the deadlock went undetected and would persist until manual intervention.

ALTER TABLE ADD COLUMN with a constant default value for the new column avoids rewriting existing tuples, instead expecting that reading code will insert the correct default into a tuple that lacks that column. If replication was subsequently initiated on the table, pgoutput would transmit NULL instead of the correct default for such a column, causing incorrect replication on the subscriber.

This case generated an improperly-formatted COPY command.

This is meant to detect cases where a subscription was created without a password (which is allowed to superusers) but then the subscription owner is changed to a non-superuser.

In some cases we’d treat this as a loggable error, which was not the intention and tends to create log spam, since common clients like psql frequently do this. It may also confuse extensions that use ClientAuthentication_hook.

Use the BIO “[.quote]#app_data”# field for our private storage, instead of assuming it’s okay to use the “[.quote]#data”# field. This mistake didn’t cause problems before, but with 3.2 it leads to crashes and complaints about double frees.

If errno isn’t set, assume the cause of the reported failure is read EOF. This fixes rare cases of strange error reports like “[.quote]#could not accept SSL connection: Success”#.

Previously, such cases failed with parsing errors due to the semicolon(s) appearing in the function body.

The pipeline state could get out of sync if an error is returned for reasons other than a query problem (for example, if the connection is lost). Potentially this would lead to a busy-loop in the calling application.

In pipeline mode, it may still be necessary to call PQflush() as well; but this change removes some inconsistency.

When using GSSAPI encryption in non-blocking mode, libpq sometimes failed with “[.quote]#GSSAPI caller failed to retransmit all data needing to be retried”#.

initdb used to work this way before v16, and now it does again. The change caused initdb’s --no-locale option to not have the intended effect on lc_messages.

Previously, commands would be included in the dump to set these properties, which is really incorrect since they should be considered as internal affairs of the extension. Moreover, the restoring user might not have adequate privilege to set them, and indeed the dumping user might not have enough privilege to dump them (since dumping RLS policies requires acquiring lock on their table).

This conforms to the behavior for other dependent objects such as indexes.

Previously, pgbench would behave oddly if a \startpipeline command lacked a matching \endpipeline. This seems like a scripting mistake rather than a case that pgbench needs to handle nicely, so throw an error.

When launching a child process via cmd.exe, pass the /D flag to prevent executing any autorun commands specified in the registry. This avoids possibly-surprising side effects.

This change avoids the need to include <simd.h> in pg_wchar.h, which was causing problems for some third-party code.

Our preferred compiler options provoke warnings about constructs appearing in recent versions of Python’s header files. When using gcc, we can suppress these warnings with a pragma.