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)

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.

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.

This occurred if VACUUM needed to update the current database’s datfrozenxid value and the database has so many granted privileges that its datacl value has been pushed out-of-line.

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.

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.

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.

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.

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

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.

Remove various assumptions that rd_smgr would stay valid over a series of operations, by wrapping all uses of it in a function that will recompute it if needed. This prevents bugs occurring when an unexpected cache flush occurs partway through such a series.

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.

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

pg_dump uses certain server functions that can fail if examining a table that gets dropped concurrently. Avoid this type of failure by ensuring that we obtain access share lock before inquiring too deeply into a table’s properties, and that we don’t apply such functions to tables we don’t intend to dump at all.

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.