PostgreSQL

In some cases involving joins, the parser failed to record all the columns read by a query in the column-usage bitmaps that are used for permissions checking. Although the executor would still insist on some sort of SELECT privilege to run the query, this meant that a user having SELECT privilege on only one column of a table could nonetheless read all its columns through a suitably crafted query.

A stored view that is subject to this problem will have incomplete column-usage bitmaps, and thus permissions will still not be enforced properly on the view after updating. In installations that depend on column-level permissions for security, it is recommended to CREATE OR REPLACE all user-defined views to cause them to be re-parsed.

The PostgreSQL Project thanks Sven Klemm for reporting this problem. (CVE-2021-20229)

If an UPDATE command attempts to move a row to a different partition but finds that it violates some constraint on the new partition, and the columns in that partition are in different physical positions than in the parent table, the error message could reveal the contents of columns that the user does not have SELECT privilege on. (CVE-2021-3393)

Concurrent insertions could lead to a corrupt index with entries placed in the wrong pages. It’s recommended to reindex any GiST index that’s been subject to concurrent insertions.

At the point where CREATE INDEX CONCURRENTLY waits for all concurrent transactions to complete so that it can see rows they inserted, it must also wait for all prepared transactions to complete, for the same reason. Its failure to do so meant that rows inserted by prepared transactions might be omitted from the new index, causing queries relying on the index to miss such rows. 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.

It was possible for aggregation grouping values to be replaced by nulls when the tuples are read back in, leading to wrong answers.

If the last tuple of a sort batch chanced to be the first tuple of the next group of already-sorted tuples, the code did the wrong thing. This could lead to “[.quote]#retrieved too many tuples in a bounded sort”# error messages, or to silently-wrong sorting results.

In PostgreSQL 13, this case reliably caused a null-pointer dereference. In earlier versions the bug seems to have no visible symptoms, but it’s not quite clear that it could never cause a problem.

A BEFORE UPDATE FOR EACH ROW trigger that modified the row in any way prevented UPDATE from moving the row to another partition when needed; but there is no longer any reason for this restriction.

If a hash-partitioned table has unequally-sized partitions (that is, varying modulus values), or it lacks partitions for some remainder values, then the planner’s pruning logic could mistakenly conclude that some partitions don’t need to be scanned, leading to failure to find rows that the query should find.

This case is unsupported (in general, a cursor using ORDER BY is not guaranteed to be simply updatable); but the code previously did not reject it, and could silently give false matches.

This occurs in particular with trivial subqueries containing lateral references to outer-join outputs. The mistake could result in a malformed plan. The known cases trigger a “[.quote]#failed to assign all NestLoopParams to plan nodes”# error, but other symptoms may be possible.

This oversight could lead to “[.quote]#no relation entry for relid `N`”# planner errors.

This oversight could lead to “[.quote]#failed to build any `N`-way joins”# planner errors.

It’s possible to use such a path by adding an explicit Sort node, and in some cases that gives rise to a superior plan.

Such cases cannot safely be pushed into worker processes, but the incremental sort feature accidentally made us consider them.

This prevents errors about missing support functions in rare edge cases.

Duplicate role or schema names within the same command could lead to “[.quote]#tuple already updated by self”# errors or unique-constraint violations.

This change ensures that permissions-related decisions will promptly reflect the results of ALTER ROLE ... [NO] INHERIT.

This is only a hazard when wal_level is set to minimal and the rewrite is performed by ALTER TABLE SET TABLESPACE.

This is only a hazard when wal_level is set to minimal.

A LIKE clause is re-examined after initial creation of the new table, to handle importation of indexes and such. It was possible for this re-examination to find a different table of the same name, causing unexpected behavior; one example is where the new table is a temporary table of the same name as the LIKE target.

This fixes the case where a self-referential foreign key constraint declared in the outer CREATE TABLE depends on an index that’s coming from the LIKE clause.

Previously, if the dropped relation spanned multiple 1GB segments, only the first segment was truncated immediately. Other segments were simply unlinked, which doesn’t authorize the kernel to release the storage so long as any other backends still have the files open.

Previously this was allowed, but subsequent operations on the partitioned relation would fail.

A backslash followed by a multibyte character was not handled correctly. In some client character encodings, this could lead to misinterpreting part of a multibyte character as a field separator or end-of-copy-data marker.

A newly-listening backend could attempt to read SLRU pages that were in process of being truncated, possibly causing an error.

We can concatenate two JSON objects or two JSON arrays. Handle other cases by wrapping non-array inputs in one-element arrays, then performing an array concatenation. Previously, some combinations of inputs followed this rule but others arbitrarily threw an error.

This error could cause the quantifier to act non-greedy, that is behave like a *? quantifier would do in full regular expressions.

Previously, a result with no significant digits was produced.

If the specified starting index and length overflow an integer when added together, substring() misbehaved, either throwing a bogus “[.quote]#negative substring length”# error for a case that should succeed, or failing to complain that a negative length is negative (and instead returning the whole string, in most cases).

The wraparound point typically falls in the middle of a page, which must be rounded off to a page boundary, and that was not done correctly. No issue could arise unless an installation had gotten to within one page of SLRU overflow, which is unlikely in a properly-functioning system. If this did happen, it would manifest in later “[.quote]#apparent wraparound”# or “[.quote]#could not access status of transaction”# errors.

Previously, if WAL archiving is enabled, a standby could fail to follow a primary running on a newer timeline, with errors like “[.quote]#requested WAL segment has already been removed”#.

The startup process did not run the deadlock detection code, so that in situations where the startup process is last to join a circular wait situation, the deadlock might never be recognized.

The code failed to traverse the HOT chain and might thus compute a too-old XID horizon, which could lead to incorrect conflict processing in hot standby. The practical impact of this bug is limited; in most cases the correct XID horizon would be found anyway from nearby operations.

Previously, which setting took precedence depended on whether the client requests GSS encryption.

This is relevant data if hostgssenc or hostnogssenc entries exist.

Remove pointless restriction that only GSS authentication can be used on a GSS-encrypted connection. Add GSS encryption information to connection-authorized log messages. Include GSS-related space when computing the required size of shared memory (this omission could have caused problems with very high max_connections settings). Avoid possible infinite recursion when reporting an unrecoverable GSS encryption error.

Previously, there was a race condition whereby a child process that had requested a background worker just before shutdown could wait indefinitely, preventing shutdown from completing.

The target XID is potentially 64 bits wide, but it was parsed with strtoul(), causing misbehavior on platforms where long is 32 bits (such as Windows).

When using OpenSSL operating in FIPS mode, SHA256 hashing is rejected, leading to an error. This change makes it possible to take a base backup on such a platform, so long as --no-manifest is specified.

No such aggregate functions exist in core PostgreSQL, but some extensions such as PostGIS provide some. The mistake is harmless anyway in a non-assert build.

A CALL in a PL/pgSQL procedure, to another procedure that has OUT parameters, would fail if the called procedure did a COMMIT or ROLLBACK.

If we successfully made a GSS-encrypted connection, but then failed during authentication, we would fall back to an unencrypted connection rather than next trying an SSL-encrypted connection. This could lead to unexpected connection failure, or to silently getting an unencrypted connection where an encrypted one is expected. Fortunately, GSS encryption could only succeed if both client and server hold valid tickets in the same Kerberos infrastructure. It seems unlikely for that to be true in an environment that requires SSL encryption instead.

This used to work, but a recent bug fix caused the password to be ignored (resulting in prompting for a password).

Formerly, they were arbitrarily truncated at 128 characters.

\help with two argument words failed to find a command description using only the first word, for example \help reset all should show the help for RESET but did not. Also, \help often failed to invoke the pager when it should. It also leaked memory.

The previous behavior resulted in (harmless) errors during restore.

Previously, these commands would be run by the role that started the restore script; which will usually work, but in corner cases that role might not have adequate permissions.

If an extension’s script creates an object and grants privileges on it with grant option, then later the user revokes such privileges, pg_dump would generate incorrect SQL for reproducing the situation. (Few if any extensions do this today.)

This prevents trying to substitute variables into timestamp literal values, which may contain strings like 12:34.

If the database name was defaulted rather than given on the command line, pg_dumpall, pgbench, oid2name, and vacuumlo would produce misleading error messages after a connection failure.

Memory consumed while producing the EXPLAIN output was not freed until the end of the current transaction (for a top-level statement) or the end of the surrounding statement (for a nested statement). This was particularly a problem with log_nested_statements enabled.

Open connections that depend on a dropped user mapping or foreign server can no longer be referenced, but formerly they were kept around anyway for the duration of the local session.

We do not really expect errors here, but this change silences warnings from static analysis tools.

Previously, autoprewarm would rewrite its status file with only the block numbers that it had managed to load so far, thus perhaps largely disabling the prewarm functionality in the next startup. Instead, suppress status file updates until the initial loading pass is complete.

The main loop in contrib/pg_prewarm’s autoprewarm parent process underestimated its desired sleep time by a factor of 1000, causing it to consume much more CPU than intended. When waiting for a result from a remote server, `contrib/postgres_fdw overestimated the desired timeout by a factor of 1000 (though this error had been mitigated by imposing a clamp to 60 seconds).

Both of these errors stemmed from incorrectly converting seconds-and-microseconds to milliseconds. Introduce a new API TimestampDifferenceMilliseconds() to make it easier to get this right in the future.

The new method is more likely to produce desirable results when Xcode is newer than the underlying operating system. Choosing a sysroot that does not match the OS version may result in nonfunctional executables.

This likewise improves the results when Xcode is out of sync with the operating system.

No field reports attributable to this have been seen, but it seems likely that it could cause problems on some architectures.

While such a call is not known to cause problems in itself, some compilers assume that the arguments of memcpy() are never NULL, which could result in incorrect optimization of nearby code.

Notably, the Australia/Currie zone has been corrected to the point where it is identical to Australia/Hobart.