PostgreSQL

Previously, this was allowed, whereupon queries on the now-out-of-sync parent would fail.

This case would lead to VACUUM failing until the old transaction terminates.

This mistake caused the planner to treat too much of the pattern as being a fixed prefix, so that indexscans derived from an ILIKE clause might miss entries that they should find.

This oversight could result in assorted failures when the offsets are nontrivial expressions. One example is that a function parameter reference in such an expression would fail if the function was inlined.

Previously, such usage might result in bogus errors about row type mismatches.

If the visible version of the row is HOT-updated, the lock might be taken on its now-dead predecessor, resulting in subtle failures to guarantee serialization.

Some code paths tried to do this after opening a file read-only, but on some platforms that causes “[.quote]#bad file descriptor”# or similar errors.

Previously, there was a hard limit of 0.25GB on the input string, but now it will work as long as the converted output is not over 1GB.

It’s no longer necessary to check for unlogged indexes here, and the check caused significant performance problems in some workloads. There was also at least a theoretical possibility of deadlock.

In some cases the tuple storage would include all columns of the source table(s), not just the ones that are needed by the query.

recovery_min_apply_delay is not typically used in this configuration, but it should work.

Declaring a column as part of the replica identity on the subscriber, when it does not exist at all on the publisher, led to “[.quote]#negative bitmapset member not allowed”# errors.

Erroneous logic prevented wal_receiver_timeout from working in logical replication deployments.

This oversight resulted, for example, in pg_stat_subscription.last_msg_send_time usually reading as NULL.

This error leads to assertion failures; it’s unclear whether any bad effects exist in production builds.

ALTER SYSTEM itself will not generate such a state, but external tools that modify postgresql.auto.conf could do so. Duplicate entries for the target variable will now be removed, and then the new setting (if any) will be appended at the end.

libpq-based clients will typically make two connection attempts when a password is required, since they don’t prompt their user for a password until their first connection attempt fails. Therefore the server is coded not to generate useless log spam when a client closes the connection upon being asked for a password. However, the PAM authentication code hadn’t gotten that memo, and would generate several messages about a phantom authentication failure.

If a time zone with a time-varying UTC offset is specified, then a date must be as well, so that the offset can be resolved. Depending on the syntax used, this check was not enforced in some cases, allowing bogus output to be produced.

The bitstring right shift operator failed to zero out padding space that exists in the last byte of the result when the bitstring length is not a multiple of 8. While invisible to most operations, any nonzero bits there would result in unexpected comparison behavior, since bitstring comparisons don’t bother to ignore the extra bits, expecting them to always be zero.

If you have inconsistent data as a result of saving the output of bitshiftright() in a table, it’s possible to fix it with something like

A GIN posting list item can require 7 bytes if the distance between adjacent indexed TIDs exceeds 16TB. One step in the logic was out of sync with that, and might try to write the value into a 6-byte buffer. In principle this could cause a stack overrun, but on most architectures it’s likely that the next byte would be unused alignment padding, making the bug harmless. In any case the bug would be very difficult to hit.

The query’s output order could be wrong (different from a plain sort’s result) if some distances computed for non-null column values are infinity or NaN.

This risk was created by a misplaced declaration: ecpg_gettext() should not be visible to client code.

Ordinarily this is unnecessary since the state would be the same anyway. But it can matter in corner cases, such as where the connection might lead to one of several servers. This change causes psql to re-issue any interactive messages that it would have issued at startup, for example about whether SSL is in use.

Previously, if two triggers on different tables had the same names, they would be sorted in OID-based order, which is less desirable than sorting them by table name. Likewise for RLS policies.

A previous fix caused pg_dump to always try to query pg_opfamily, but that catalog doesn’t exist before version 8.3.

This synchronizes pg_restore’s behavior with some other applications, and in particular makes pre-v12 branches act similarly to version 12’s pg_restore, simplifying creation of dump/restore scripts that work across multiple PostgreSQL versions. Before this change, pg_restore interpreted such a switch as meaning “[.quote]#output to a file named -”#, but few people would want that.

The previous coding could be fooled by cases where the data type of interest underlies a stored column of a domain or composite type.

The previous coding could result in timeout failures if fsync was slow.

An unlogged index won’t necessarily contain valid data in this context, so don’t try to check it.

A clause like `array_column+ <@ `_`+constant_array`_ is considered indexable, but the index search may not find empty array values; of course, such entries should trivially match the search.

The only practical back-patchable fix for this requires making <@ index searches scan the whole index, which is what this patch does. This is unfortunate: it means that the query performance is likely worse than a plain sequential scan would be.

Applications whose performance is adversely impacted by this change have a couple of options. They could switch to a GIN index, which doesn’t have this bug, or they could replace `array_column+ <@ `_`+constant_array_ with array_column+ <@ `_`+constant_array+ AND `_`+array_column+ && `_`+constant_array`_. That will provide about the same performance as before, and it will find all non-empty subsets of the given constant array, which is all that could reliably be expected of the query before.

Previously, it could fail if the user sets CFLAGS to -O0.

The previous spinlock coding allowed the compiler to select register zero for use with an assembly instruction that does not accept that register, causing a build failure. We have seen only one long-ago report that matches this bug, but it could cause problems for people trying to build modified PostgreSQL code or use atypical compiler options.

xlc 13 and newer interpret this function in a way incompatible with our usage, resulting in an unusable build of PostgreSQL. Fix by using custom assembly code instead.

This avoids an internal compiler error with xlc v16.1.0, with little consequence other than changing the format of compiler error messages.