PostgreSQL

This change prevents extension scripts from doing CREATE OR REPLACE if there is an existing object that does not belong to the extension. It also prevents CREATE IF NOT EXISTS in the same situation. This prevents a form of trojan-horse attack in which a hostile database user could become the owner of an extension object and then modify it to compromise future uses of the object by other users. As a side benefit, it also reduces the risk of accidentally replacing objects one did not mean to.

The PostgreSQL Project thanks Sven Klemm for reporting this problem. (CVE-2022-2625)

Standby servers may encounter missing tablespace directories when replaying database-creation WAL records. Prior to this patch, a standby would fail to recover in such a case; however, such directories could be legitimately missing. Create the tablespace (as a plain directory), then check that it has been dropped again once replay reaches a consistent state.

Normally a Postgres tablespace is a symbolic link to a directory on some other filesystem. This change allows it to just be a plain directory. While this has no use for separating tables onto different filesystems, it is a convenient setup for testing. Moreover, it is necessary to support the CREATE DATABASE replay fix, which transiently creates a missing tablespace as an “[.quote]#in place”# tablespace.

The fix for CVE-2022-1552 caused CREATE INDEX to apply the table owner’s permissions while performing lookups of operator classes and other objects, where formerly the calling user’s permissions were used. This broke dump/restore scenarios, because pg_dump issues CREATE INDEX before re-granting permissions.

If the client does not send a Sync message immediately after such a command, but instead sends another command, any failure in that command would lead to rolling back the preceding command, typically leaving inconsistent state on-disk (such as a missing or extra database directory). The mechanisms intended to prevent that situation turn out to work for multiple commands in a simple-Query message, but not for a series of extended-protocol messages. To prevent inconsistency without breaking use-cases that work today, force an implicit commit after such commands.

TransactionIdIsInProgress could report false before the subject transaction is considered visible, leading to various misbehaviors. The race condition window is normally very narrow, but use of synchronous replication makes it much wider, because the wait for a synchronous replica happens in that window.

If there are extended statistics on a table that the user has only partial SELECT permissions on, some queries would fail with “[.quote]#unrecognized node type”# errors.

Statistics collection worked fine, but a query containing such an expression in WHERE would fail with “[.quote]#unknown clause type”#.

In certain cases, a “[.quote]#trigger does not exist”# failure would occur because the command would try to adjust the trigger on a child partition that doesn’t have it.

In some scenarios with high statistics targets, it was possible to spend many seconds in an un-cancellable sort operation.

This omission could lead to assertion failures or crashes later in the session.

In corner cases, a misleading error could be reported.

Cases with more than about 1600 columns are unsupported, and have always failed at execution. However, it emerges that some earlier code could be driven to assertion failures or crashes by queries with more than 32K columns. Add a parse-time check to prevent that.

This oversight could lead to dump/reload or pg_upgrade failures, as the dumped view would have too many column aliases for the function.

The replica identity columns have to be re-identified for the child partition.

Proper cleanup is complicated and requires use of low-level facilities, so it’s not surprising that no known caller got it right. This led to misbehaviors when a PL procedure issued COMMIT but a failure occurred (such as a deferred constraint check). To improve matters, redefine SPI_commit() as starting a new transaction, so that it becomes equivalent to SPI_commit_and_chain() except that you get default transaction characteristics instead of preserving the prior transaction’s characteristics. To make this somewhat transparent API-wise, redefine SPI_start_transaction() as a no-op. All known callers of SPI_commit() immediately call SPI_start_transaction(), so they will not notice any change. Similar remarks apply to SPI_rollback().

Also fix PL/Python, which omitted any handling of such errors at all, resulting in jumping out of the Python interpreter. This is reported to crash Python 3.11. Older Python releases leak some memory but seem okay with it otherwise.

This fixes “[.quote]#message type 0x33 arrived from server while idle”# warnings, as well as possible loss of end-of-query NULL results from PQgetResult().

Certain operations such as EXEC SQL PREPARE would crash (rather than reporting an error as expected) if called before establishing any database connection.

Allocate a C locale object once per process when first connecting, rather than creating and freeing locale objects once per query. This mitigates a libc memory leak on AIX, and may offer some performance benefit everywhere.

This prevents libedit (and possibly also libreadline) from becoming confused about which column the cursor is in.

Version 14 changed some built-in functions to take type anycompatiblearray instead of anyarray. While this is mostly transparent, user-defined aggregates and operators built atop these functions have to be declared with exactly matching types. The presence of an object referencing the old signature will cause pg_upgrade to fail, so change it to detect and report such cases before beginning the upgrade.

Such constraints cannot be checked properly if more than one row is inserted at a time.

This avoids problems when a signal interrupts posix_fallocate().

This avoids a possible crash on Solaris.

This appears to trigger hangs and kernel panics, so avoid the function until a fix is available.