PostgreSQL

A man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could be abused to send faked SQL commands to the server, although that would only work if the server did not demand any authentication data. (However, a server relying on SSL certificate authentication might well not do so.)

The PostgreSQL Project thanks Jacob Champion for reporting this problem. (CVE-2021-23214)

A man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could probably be abused to inject faked responses to the client’s first few queries, although other details of libpq’s behavior make that harder than it sounds. A different line of attack is to exfiltrate the client’s password, or other sensitive data that might be sent early in the session. That has been shown to be possible with a server vulnerable to CVE-2021-23214.

The PostgreSQL Project thanks Jacob Champion for reporting this problem. (CVE-2021-23222)

If the primary did not survive long enough to finish writing the rest of the incomplete WAL record, then the previous crash-recovery logic had it back up and overwrite WAL starting from the beginning of the incomplete WAL record. This is problematic since standby servers may already have copies of that WAL segment. They will then see an inconsistent next segment, and will not be able to recover without manual intervention. To fix, do not back up over a WAL segment boundary when restarting after a crash. Instead write a new type of WAL record at the start of the next WAL segment, informing readers that the incomplete WAL record will never be finished and must be disregarded.

When applying this update, it’s best to update standby servers before the primary, so that they will be ready to handle this new WAL record type if the primary happens to crash.

Rows inserted by just-prepared transactions might be omitted from the new index, causing queries relying on the index to miss such rows. The previous fix for this type of problem failed to account for PREPARE TRANSACTION commands that were still in progress when CREATE INDEX CONCURRENTLY checked for them. As before, in installations that have enabled prepared transactions (max_prepared_transactions > 0), it’s recommended to reindex any concurrently-built indexes in case this problem occurred when they were built.

While it’s apparently rare in the field, this case could potentially affect any index built or reindexed with the CONCURRENTLY option. It is recommended to reindex any such indexes to make sure they are correct.

Since PostgreSQL’s floating-point types deem all NaNs to be equal, it’s important for the hash functions to produce the same hash code for all bit-patterns that are NaNs according to the IEEE 754 standard. This failed to happen before, meaning that hash indexes and hash-based query plans might produce incorrect results for non-canonical NaN values. ('-NaN'::float8 is one way to produce such a value on most machines.) It is advisable to reindex hash indexes on floating-point columns, if there is any possibility that they might contain such values.

If the server crashed between CREATE TABLESPACE and the next checkpoint, replay would fully remove the contents of the new tablespace’s directory, relying on subsequent WAL replay to restore everything within that directory. This interacts badly with optimizations that skip writing WAL (one example is COPY into a just-created table). Such optimizations are applied only when wal_level is minimal, which is not the default in v10 and later.

This oversight could allow misbehavior of subsequent inserts/updates addressed directly to the partition, but only in currently-existing sessions.

This oversight could lead to improper replication behavior until all currently-existing sessions have exited.

For example, if column f1 is of type numeric(18,3), the parser used to simply discard a cast like f1::numeric, on the grounds that it would have no run-time effect. That’s true, but the exposed type of the expression should still be considered to be plain numeric, not numeric(18,3). This is important for correctly resolving the type of larger constructs, such as recursive `UNION`s.

A command such as UPDATE tab SET fld[1].subfld = val failed if the array’s elements were domains rather than plain composites.

Previously this was allowed, but then the collation could not be referenced because of the way collation lookup works; you could not use the collation, nor even drop it.

The result could be inaccurate when the first argument is very close to 1.

Regular expressions like (.){0}...\1 drew “[.quote]#invalid backreference number”#. Other regexp engines such as Perl don’t complain, though, and for that matter ours doesn’t either in some closely related cases. Worse, it could throw an assertion failure instead. Fix it so that no error is thrown and instead the back-reference is silently deemed to never match.

The regexp engine was careless about clearing match data for capturing parentheses after rejecting a partial match. This could allow a later back-reference to match in places where it should fail for lack of a defined referent.

Incorrect back-tracking logic could result in exponential time spent looking for a match. Fortunately the problem is masked in most cases by other optimizations.

The results were incorrect if the target time zone was specified by a dynamic timezone abbreviation (that is, one that is defined as equivalent to a full time zone name, rather than a fixed UTC offset).

There are corner cases in which ANALYZE will build a most-common-values (MCV) list but not a histogram, even though the MCV list does not account for all the observed values. In such cases, keep the planner from using the MCV list alone to estimate the range of column values.

If a procedure commits or rolls back a transaction, and then its next significant action is inside a new subtransaction, snapshot management went wrong, leading to a dangling pointer and probable crash. A typical example in PL/pgSQL is a COMMIT immediately followed by a BEGIN ... EXCEPTION block that performs a query.

This oversight would only cause a problem if the same session attempted to export a snapshot again. The most likely scenario for that is creation of a replication slot (followed by rollback) and then creation of another replication slot.

This oversight could cause significant performance degradation (manifesting as excessive SubtransSLRU traffic) on standby servers.

There was a narrow window where a prepared transaction could be omitted from a snapshot taken by a concurrently-running session. If that session then used the snapshot to perform data updates, erroneous results or data corruption could occur.

We have long forbidden fetching backwards from a NO SCROLL cursor, but for historical reasons the prohibition didn’t extend to cases in which we rewind the query altogether and then re-fetch forwards. That exception leads to inconsistencies, particularly for held-over cursors which may not have stored all the data necessary to rewind. Disallow rewinding for non-scrollable held-over cursors to block the worst inconsistencies. (v15 will remove the exception altogether.)

An attempt to extend a table or index past the limit of 2^32-1 blocks was rejected, but not soon enough to prevent inconsistent internal state from being created.

The previous failure to do this could lead to problems such as unsafely choosing a parallel plan.

The code typically produced “[.quote]#cache lookup error”# rather than the intended message.

This oversight could lead to misbehavior in parallel queries if the transaction isolation level is less than REPEATABLE READ.

Logical decoding normally ignores changes in transient tables such as those created during an ALTER TABLE heap rewrite. But that filtering wasn’t applied to the associated toast table if any, leading to possible errors when rewriting a table that’s being published.

If a walreceiver exited exactly at a WAL segment boundary, it failed to make a notification file for the last-received segment, thus delaying archiving of that segment on the standby.

If the FILTER expression is a plain boolean column, the semantic level of the aggregate could be mis-determined, leading to not-per-spec behavior. If the FILTER expression is itself a boolean-returning aggregate, an error should be thrown but was not, likely resulting in a crash at execution.

This prevents a likely crash during backend exit after a fatal LLVM error.

Incrementing the number-of-index-scans counter was overlooked in the SP-GiST code, although per-tuple counters were advanced correctly.

It seems unlikely that this bug has been hit in practice, as it would require work_mem settings of hundreds of gigabytes for existing uses of simplehash.h.

They were being called with an out-of-date snapshot, so that they would not see any database changes made since the start of the session’s top-level command.

If the routine does not require an explicit RETURN, this usage should be valid, but it was rejected.

For example, this removes a restriction on how many command-line options can be passed through to the postmaster. Individual path names that pg_ctl deals with, such as the postmaster executable’s name or the data directory name, are still limited to MAXPGPATH bytes in most cases.

If a global (unrestricted) ALTER DEFAULT PRIVILEGES command revoked some present-by-default privilege, for example EXECUTE for functions, and then a restricted ALTER DEFAULT PRIVILEGES command granted that privilege again for a selected role or schema, pg_dump failed to dump the restricted privilege grant correctly.

This oversight was usually pretty harmless, since once pg_dump has locked any of the leaf partitions, that would suffice to prevent significant DDL on the partitioned table itself. However problems could ensue when dumping a childless partitioned table, since no relevant lock would be held.

These changes provide only marginal improvement when dumping from a local server, but a dump from a remote server can benefit substantially due to fewer network round-trips.

Such an indexscan failed to return all the entries it should.

Such large query text files are very unusual, but if they do occur, the previous coding would fail on Windows 64 (which rejects individual read requests of more than 2GB).

This is essential for reasonable performance on that platform.

This oversight probably only matters for code that is doing tasks like auditing the OpenSSL installation. But it’s nominally a violation of the OpenSSL API, so fix it.

Return REG_NOMATCH, instead of possibly crashing, when `search_start` is past the end of the string. This case is probably unreachable within core PostgreSQL, but extensions might be more careless about the parameter value.

When running on Windows, initdb attempts to set the new cluster’s timezone parameter to the IANA time zone matching the system’s prevailing time zone. We were using a mapping table that we’d generated years ago and updated only fitfully; unsurprisingly, it contained a number of errors as well as omissions of recently-added zones. It turns out that CLDR has been tracking the most appropriate mappings, so start using their data. This change will not affect any existing installation, only newly-initialized clusters.

Also, the Pacific/Enderbury zone has been renamed to Pacific/Kanton. Also, the following zones have been merged into nearby, more-populous zones whose clocks have agreed with them since 1970: Africa/Accra, America/Atikokan, America/Blanc-Sablon, America/Creston, America/Curacao, America/Nassau, America/Port_of_Spain, Antarctica/DumontDUrville, and Antarctica/Syowa. In all these cases, the previous zone name remains as an alias.