PostgreSQL

Within a CREATE SCHEMA command, objects in the prevailing search_path, as well as those in the newly-created schema, would be visible even within a called function or script that attempted to set a secure search_path. This could allow any user having permission to create a schema to hijack the privileges of a security definer function or extension script.

The PostgreSQL Project thanks Alexander Lakhin for reporting this problem. (CVE-2023-2454)

If a set-returning SQL-language function refers to a table having row-level security policies, and it can be inlined into a calling query, those RLS policies would not get enforced properly in some cases involving re-using a cached plan under a different role. This could allow a user to see or modify rows that should have been invisible.

The PostgreSQL Project thanks Wolfgang Walther for reporting this problem. (CVE-2023-2455)

The SQL standard allows writing CREATE SCHEMA AUTHORIZATION +`_`+owner_name`, with the schema name defaulting to _owner_name`. However some code paths expected the schema name to be present and would fail.

ALTER TABLE ... ENABLE/DISABLE TRIGGER USER skipped cloned triggers, mistaking them for system triggers. Other variants of ENABLE/DISABLE TRIGGER would process them, but only after improperly enforcing a superuserness check.

ALTER TYPE disallows non-binary-compatible modifications of composite types if they are stored in any table columns. (Perhaps that will be allowed someday, but it hasn’t happened yet; the locking implications of rewriting many tables are daunting.) We overlooked the possibility that an index might contain a composite type that doesn’t also appear in its table.

Since the removal of OID as a system column, there is no plausible use-case for this, and various bits of code no longer support it. Disallow it rather than trying to fix all the cases.

The documentation is quite clear that COPY TO copies rows from only the named table, not any inheritance children it may have. However, if row-level security was enabled on the table then this stopped being true.

With bad luck this could have resulted in a server crash.

When using the deletion feature, the function might fetch the byte just after the input string, creating a small risk of crash.

Most cases in which a syntax error is detected in a string literal within a JSON value failed to set the error cursor appropriately. This led at least to an unhelpful error message (pointing to the token before the string, rather than the actual trouble spot), and could even result in a crash in v14 and later.

In v14 and later with non-default settings of vacuum_defer_cleanup_age, it was possible to compute a very large vacuum cleanup horizon xid, leading to vacuum removing rows that are still live. v12 and v13 have a lesser form of the same problem affecting only GiST indexes, which could lead to index pages getting recycled too early.

This oversight could lead to executor failures for queries that should have been rejected as invalid.

This can lead to trouble if an event trigger captures the corrupted parse tree.

This planner oversight could lead to “[.quote]#subplan was not initialized”# errors at runtime.

Use of dependency-type extended statistics could fail with “[.quote]#PlaceHolderVar found where not expected”#.

This optimization requires that the aggregate’s argument expressions have repeatable results, which might not hold for a sub-SELECT.

Correctly detect overflow of the total space needed for the result array, avoiding a possible crash due to undersized output allocation. Also ensure that any trailing padding space in the result array is zeroed; while leaving garbage there is harmless for most purposes, it can result in odd behavior later.

Pruning with a condition like boolcol IS NOT TRUE was done incorrectly, leading to possibly not returning rows in which boolcol is NULL. Also, the rather unlikely case of partitioning on NOT boolcol was handled incorrectly.

A crash was possible given unlucky timing and parallel_leader_participation = off (which is not the default).

In READ COMMITTED isolation mode, the effects of a row update might need to get reapplied to a newer version of the row than the query found originally. If so, we need to recompute any GENERATED columns, in case they depend on columns that were changed by the concurrent update.

Delay balancing is supposed to be disabled whenever autovacuum is processing a table with a per-relation vacuum_cost_delay setting, but this was done only for positive settings, not zero.

Use of the syntax INSERT ... ON CONFLICT DO UPDATE SET (c1, ...) = (SELECT ...) with a partitioned target table could result in failure if any child table is dissimilar from the parent (for example, different physical column order). This typically manifested as failure of consistency checks in the executor; but a crash or incorrect data updates are also possible.

Such cases typically failed with “[.quote]#unrecognized node type”# errors or assertion failures.

Such references are really lateral references, but the server could crash if the subquery wasn’t explicitly marked with LATERAL. Arrange to do that implicitly when necessary.

Transactions already marked as “[.quote]#doomed”# confused the safe-snapshot optimization for SERIALIZABLE READ ONLY transactions. The optimization was unnecessarily skipped in some cases. In other cases an assertion failure occurred (but there was no problem in non-assert builds).

Multiple cycles of starting up and shutting down the plugin within a single session would eventually lead to an “[.quote]#out of relcache_callback_list slots”# error.

This change fixes some cases where an unexpected error was thrown.

The existing code effectively considered only the last scan key while deciding whether a range matched, thus usually scanning more of the index than it needed to.

This error triggered an assertion failure in assert-enabled builds, but is mostly harmless in production builds.

This error seems to usually be harmless in production builds, as the fetched value is noncritical; but in principle it could cause a server crash.

Replication with the REPLICA IDENTITY FULL option failed if the table contained such columns.

This wait event is named CommitTsBuffer according to the documentation, but the code had it as CommitTSBuffer. Change the code to match the documentation, as that way is more consistent with the naming of related wait events.

Reporting of this type of wait was accidentally removed in code refactoring.

This could result in not honoring wal_keep_size accurately.

This feature requires building with OpenSSL 1.1.1 or newer. Both the server and libpq are affected.

The operating system could recycle a PID before the postmaster observed that that child process was gone. This could lead to tracking more than one child with the same PID, resulting in confusion.

In the unusual case where the size of a large (>8kB) palloc chunk is decreased, a Valgrind-aware build would mismark the defined-ness state of the memory released from the chunk, possibly causing incorrect results during Valgrind testing.

A backslash followed by a non-ASCII character could sometimes cause an assertion failure, depending on the prevailing locale.

It is not entirely clear whether this case is reachable in released branches, but if it is then an assertion failure could occur.

plperl could misbehave when the nesting of sub-lists is inconsistent so that the data does not represent a rectangular array of values. Such cases now produce errors, but previously they could result in a crash or garbage output.

plpython could misbehave when dealing with empty sub-lists, or when the nesting of sub-lists is inconsistent so that the data does not represent a rectangular array of values. The former should result in an empty output array, and the latter in an error. But some cases resulted in a crash, and others in unexpected output.

Some rare failure cases could return without cleaning up the PG_TRY exception stack, risking a crash if another error was raised before the next stack level was unwound.

With gssencmode set to require, the connection was not marked dead after a GSS initialization failure. Make it fail immediately, as the equivalent case for TLS encryption has long done.

When ecpg_get_data() is called with varcharsize set to zero, it could write a terminating zero character into the last byte of the preceding field, truncating the data in that field.

Since the hash codes for enum values depend on the OIDs assigned to the enum, they are typically different after a dump and restore, meaning that rows often need to go into a different partition than they were in originally. Users can work around that by specifying the --load-via-partition-root option; but since there is very little chance of success without that, teach pg_dump to apply it automatically to such tables.

Also, fix pg_restore to not try to TRUNCATE target tables before restoring into them when --load-via-partition-root mode is used. This avoids a hazard of deadlocks and lost data.

This bug led to misbehavior when pg_dump writes to a pipe or pg_restore reads from one.

This avoids a failure when a pgbench script tries to start a serializable transaction inside a pipeline.

In cases of corruption we might see a wrapped-around 32-bit xid that appears to be before the first xid epoch. Promoting such a value to 64-bit form produced a value far in the future, resulting in wrong reports. Return FirstNormalFullTransactionId in such cases so that things work reasonably sanely.

This should give an error, but Python 3 changed some APIs in a way that caused the check to misbehave, allowing a crash to ensue.

Other values result in misaligned accesses to index content, which is harmless on Intel-compatible hardware but can cause a crash on some other architectures.

A regex such as $foo is legal but unsatisfiable; the regex compiler recognizes that and produces an empty NFA graph. Attempting to optimize such a graph into a pg_trgm GIN or GiST index qualification resulted in accessing off the end of a work array, possibly leading to crashes.

Previously, make install-strip used the -x option in this case. This change avoids misbehavior of llvm-strip, and gives slightly smaller output as well.

It appears no longer possible to build the SGML documentation without a local installation of the DocBook DTD files. Formerly xsltproc could download those files on-the-fly from sourceforge.net; but sourceforge.net now permits only HTTPS access, and no common version of xsltproc supports that. Hence, remove the bits of our documentation suggesting that that’s possible or useful, and instead add xsltproc’s --nonet option to the build recipes.

Place it under tmp_check in the build directory. With the previous coding, a PGXS build would try to place it in the installation directory, which is not necessarily writable.

When observing Moscow time, Europe/Kirov and Europe/Volgograd now use the abbreviations MSK/MSD instead of numeric abbreviations, for consistency with other timezones observing Moscow time. Also, America/Yellowknife is no longer distinct from America/Edmonton; this affects some pre-1948 timestamps in that area.