PostgreSQL

A modified server, or an unauthenticated man-in-the-middle, can send a not-zero-terminated error message during setup of GSSAPI (Kerberos) transport encryption. libpq will then copy that string, as well as following bytes in application memory up to the next zero byte, to its error report. Depending on what the calling application does with the error report, this could result in disclosure of application memory contents. There is also a small probability of a crash due to reading beyond the end of memory. Fix by properly zero-terminating the server message. (CVE-2022-41862)

This fixes failure to update GENERATED columns that do not exist in the parent table, or that have different dependencies than are in the parent column’s generation expression.

When the first row-level action of the MERGE was an UPDATE, any subsequent INSERT actions would fail to compute GENERATED columns that were deemed unnecessary to compute for the UPDATE action (due to not depending on any of the UPDATE target columns).

A WHEN clause following an unconditional WHEN clause should be rejected as unreachable, but this case was not always detected.

MERGE is not supported on tables with rules; but it also failed on tables that once had rules but no longer do.

This makes the code’s behavior match the documentation.

A reference to the SET column from within the CTE would fail with “[.quote]#cache lookup failed for type 0”#.

In some cases pending insertions were not flushed to the FDW soon enough, leading to logical inconsistencies, for example BEFORE ROW triggers not seeing rows they should be able to see.

When pg_dump dumps a partitioned index that’s marked REPLICA IDENTITY, it generates a command sequence that applies REPLICA IDENTITY before the partitioned index has been marked valid, causing restore to fail. There seems no very good reason to prohibit doing it in that order, so allow it. The marking will have no effect anyway until the index becomes valid.

In some cases a DEFAULT marker would not get replaced with the proper default-value expression, leading to an “[.quote]#unrecognized node type”# error.

While jsonpath match operators threw an error for an undefined variable in the path pattern, the existence operators silently treated it as a match.

Using a text value fetched directly from a table as a jsonb subscript was likely to fail. Fetches would usually not find any matching element. Assignments could store the value with a garbage key, although keys long enough to cause that problem are probably rare in the field.

If the final chunk of a large tuple being written out to a temporary file was exactly 32760 bytes, it would be corrupted due to a fencepost bug. The query would typically fail later with corrupted-data symptoms.

Internal state was not updated after a change in checkpoint_completion_target, possibly resulting in performing checkpoint I/O faster or slower than desired, especially if that setting was changed on-the-fly.

When ending recovery based on the recovery_target_xid setting with recovery_target_inclusive = off, we printed an incorrect timestamp (always 2000-01-01) in the “[.quote]#recovery stopping before …​ transaction”# log message.

Correctly report a short read, giving the numbers of bytes desired and actually read, instead of reporting an irrelevant error code. Most places got this right already, but some recently-written replication logic did not.

The input functions for these types previously rejected more than 100 elements. With the introduction of the logical replication column list feature, it’s necessary to accept `int2vector`s having up to 1600 columns, otherwise long column lists cause logical-replication failures.

If there’s not been an explicit BEGIN TRANSACTION, ANALYZE would take it on itself to commit, which should not happen within a pipelined series of commands.

The server would process a cancel request even if its length word was too small. This led to reading beyond the end of the allocated buffer. In theory that could cause a segfault, but it seems quite unlikely to happen in practice, since the buffer would have to be very close to the end of memory. The more likely outcome was a bogus log message about wrong backend PID or cancel code. Complain about the wrong length, instead.

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

In practice, because the run-condition optimization is only applied to certain window functions that happen to all return int8, this only manifested as a problem on 32-bit builds.

A contrived query can result in deep recursion and unreasonable amounts of time spent trying to flatten subqueries. A proper fix for that seems unduly invasive for a back-patch, but we can at least add stack depth checks and an interrupt check to allow the query to be cancelled.

These errors could lead to not using Memoize in contexts where it would be useful, or possibly to wrong query plans.

This could result in “[.quote]#could not devise a query plan for the given query”# errors.

Planner runs occurring just after deletion of a large number of tuples appearing at the end of an index could expend significant amounts of work setting the “[.quote]#killed”# bits for those index entries. Limit the amount of work done in any one query by giving up on this process after examining 100 heap pages. All the cleanup will still happen eventually, but without so large a performance hiccup.

Converting a table to a view could lead to crashes or assertion failures.

This could result in dump/restore failures for rules or views in which an argument of AT TIME ZONE is itself an expression.

If a SQL-language function executes the same utility command more than once within a single calling query, it could crash or report strange errors such as “[.quote]#unrecognized node type”#.

This was caused by an ill-advised choice to block interrupts while creating a logical replication slot in the worker. In version 15 that could lead to an undetected deadlock. In version 14, no deadlock has been observed, but it’s still a bad idea to block interrupts while waiting for network I/O.

The previous coding leaked the connection object. In background code paths that’s pretty harmless because the calling process will give up and exit. But in commands such as CREATE SUBSCRIPTION, such a failure resulted in a small session-lifespan memory leak.

Insufficiently-aggressive cleanup of the KnownAssignedXids array could lead to poor performance, particularly when max_connections is set to a large value on the standby.

A replication slot could prevent cleanup of dead tuples in the system catalogs even after it becomes invalidated due to exceeding max_slot_wal_keep_size. Thus, failure of a replication consumer could lead to indefinitely-large catalog bloat.

After a server restart, we’ll re-stream the changes for transactions occurring shortly before the restart. Some of these transactions probably never completed; when we realize that one didn’t we throw away the relevant decoding state locally, but we neglected to tell the subscriber about it. That led to the subscriber keeping useless streaming files until it’s next restarted.

In certain cases, resumption of logical decoding could try to re-use XID data that had already been freed, leading to unpredictable behavior.

We neglected to acquire the appropriate lock while updating data about two-phase transactions, potentially allowing other processes to see inconsistent data.

UPDATE and DELETE events did not pay attention to the configured column list, thus sending more data than expected. This did not cause a problem when the receiver is our built-in logical replication code, but it might confuse other receivers, and in any case it wasted network bandwidth.

Failure to do this left the page possibly different on standby servers than the primary, and violated some other expectations about when the LSN changes. This seems only a theoretical hazard so far as PostgreSQL itself is concerned, but it could upset third-party tools.

This function misbehaved with some values of its second argument. No such usages exist in core PostgreSQL, but it’s clearly a hazard for external modules, so repair.

The epoll-based and kqueue-based implementations could ask the kernel for too many events if the size of their internal buffer was different from the size of the caller’s output buffer. That case is not known to occur in released PostgreSQL versions, but this error is a hazard for external modules and future bug fixes.

clang’s undefined-behavior sanitizer complained about use of a pointer that was less aligned than it should be. It’s very unlikely that this would cause a problem in non-debug builds, but it’s worth fixing for testing purposes.

The assertion was overly strict, so this mistake was harmless in non-assert builds.

In principle these errors should never be reached. But if they are, some of them reported the wrong type of object.

If the public schema has a non-default owner then use of pg_dump’s --if-exists option resulted in a warning message “[.quote]#warning: could not find where to insert IF EXISTS in statement "-- not dropping schema, since initdb creates it"”#. The dump output was okay, though.

These commands misidentified the start of the function body when it used new-style syntax.

This avoids possible failure if one of these functions is used to examine a temporary table, since a session’s temporary tables are not accessible from parallel workers.

A previous patch supposed that all platforms of interest have snprintf(), but MSVC 2013 isn’t quite there yet. Revert to using sprintf() on that platform.

Such combinations could previously fail with “[.quote]#loadable library and perl binaries are mismatched”# errors.

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

Notably, a new timezone America/Ciudad_Juarez has been split off from America/Ojinaga.