PostgreSQL

If a concurrent VACUUM sets the all-visible flag bit in a page that UPDATE or DELETE is in process of modifying, the updating command needs to clear that bit again; but some code paths failed to do so, ending in a PANIC exit and database restart.

This is known to be possible in versions 14 and 15. It may be only latent in previous branches.

Rather than throwing an error, just log the issue and continue without deleting the empty page. Previously, a buggy operator class or corrupted index could indefinitely prevent completion of vacuuming of the index, eventually leading to transaction wraparound problems.

This oversight could lead to “[.quote]#cache lookup failed for type”# errors, or in older branches even to crashes.

This avoids confusion between a view’s ON SELECT rule and any other rules it may have.

Given the right circumstances, this manifested as a “[.quote]#tupdesc reference `NNNN` is not owned by resource owner”# error followed by a PANIC exit.

Use of the syntax UPDATE tab SET (c1, ...) = (SELECT ...) with an inherited or partitioned target table could result in failure if the child tables are sufficiently dissimilar. This typically manifested as failure of consistency checks in the executor; but a crash or incorrect data updates are also possible.

Previously, incorrect or duplicate constraints could be constructed for the newly-added partition.

If the initially-given name is already in use for some constraint of the partition, a new one is selected; but it wasn’t being spelled as intended.

While creating a partitioned index, we try to identify any existing indexes on the partitions that match the partitioned index, so that we can absorb those as child indexes instead of building new ones. Matching of expressions was not done right, so that a usable child index might be ignored, leading to creation of a duplicative index.

When a PostgreSQL instance performing archive recovery (but not using standby mode) is promoted, and the last WAL segment that it attempted to read ended in a partial record, the instance would write an invalid WAL segment on the new timeline.

This mistake is not known to have any negative consequences within core PostgreSQL, but it did cause issues for some extensions.

These errors could lead to assertion failures in debug builds, and otherwise to memory leaks.

If decoding begins partway through a transaction that modifies system catalogs, the decoder may not recognize that, causing it to fail to treat that transaction as in-progress for catalog lookups.

This ameliorates problems with slow shutdown of replication workers.

If a syntax error occurred in a SQL-language or PL/pgSQL-language CREATE FUNCTION or DO command executed in a logical replication worker, the worker process would crash with a null pointer dereference or assertion failure.

If a non-inlined SQL function uses a parameter in more than one place, and one of those functions expects to be able to modify read-write datums in place, then later uses of the parameter would observe the wrong value. (Within core PostgreSQL, the expanded-datum mechanism is only used for array and composite-type values; but extensions might use it for other structured types.)

If the left-hand circle had a floating-point NaN for its radius, it would be considered equal to a circle with the same center and any radius.

If the input word exceeds 1000 bytes, return it as-is after case folding, rather than trying to run it through the Snowball code. This restriction protects against a known recursion-to-stack-overflow problem in the Turkish stemmer, and it seems like good insurance against any other safety or performance issues that may exist in the Snowball stemmers. Such a long string is surely not a word in any human language, so it’s doubtful that the stemmer would have done anything desirable with it anyway.

Improper memory management in the string comparison functions could result in scribbling on no-longer-allocated buffers, potentially breaking things for whatever is using that memory now. This would only happen with fairly long strings (more than 1kB), and only if an ICU collation is in use.

This prevents a crash in some catalog-corruption scenarios, for example use of a view whose ON SELECT rule is missing.

The postmaster process is supposed to survive and initiate a database restart if shared memory becomes corrupted, but one bit of code was being insufficiently cautious about that.

The lack of field reports suggests that this problem is only latent in pre-v15 branches; but it’s not very clear why, so back-patch the fix anyway.

Build a separate function cache entry for each concrete type passed to the RECORD parameter during a session, much as we do for polymorphic parameters. This allows some usages to work that previously failed with errors such as “[.quote]#type of parameter does not match that when preparing the plan”#.

There’s a convention that libpq functions should check for a NULL PGconn argument, and fail gracefully instead of crashing. PQflush() and PQisnonblocking() didn’t get that memo, so fix them.

For example, ecpg translated static varchar str1[10], str2[20], str3[30]; in such a way that only str1 was marked static.

Allow the remote path in --tablespace-mapping to be either a Unix-style or Windows-style absolute path, since the source server could be on a different OS than the local system.

This occurred if pg_stat_statements tracked a ROLLBACK command issued via extended query protocol. In debug builds it consistently led to an assertion failure. In production builds there would often be no visible ill effect; but if the freed memory had already been reused, the likely result would be to store garbage for the query string.

This avoids “[.quote]#variable not found in subplan target list”# errors in rare cases.

The uuid-ossp module expects libc’s uuid_create() to produce a version-1 UUID, but recent NetBSD releases produce a version-4 (random) UUID instead. Check for that, and complain if so. Drop the documentation’s claim that the NetBSD implementation is usable for uuid-ossp. (If a version-4 UUID is okay for your purposes, you don’t need uuid-ossp at all; just use gen_random_uuid().)

Add PostgreSQL/Test/Cluster.pm and PostgreSQL/Test/Utils.pm to the standard installation file set in pre-version-15 branches. This is for the benefit of extensions that want to use newly-written test code in older branches.

This avoids a risk of deadlock in the dynamic linker on NetBSD 10.

This eases porting to new machine architectures, at least if you’re using a compiler that supports this GCC builtin function.

Also, the Europe/Kiev zone has been renamed to Europe/Kyiv. Also, the following zones have been merged into nearby, more-populous zones whose clocks have agreed with them since 1970: Antarctica/Vostok, Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake and Pacific/Wallis. (This indirectly affects zones that were already links to one of these: Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape, Pacific/Truk, and Pacific/Yap.) America/Nipigon, America/Rainy_River, America/Thunder_Bay, Europe/Uzhgorod, and Europe/Zaporozhye were also merged into nearby zones after discovering that their claimed post-1970 differences from those zones seem to have been errors. In all these cases, the previous zone name remains as an alias; but the actual data is that of the zone that was merged into.

These zone mergers result in loss of pre-1970 timezone history for the merged zones, which may be troublesome for applications expecting consistency of timestamptz display. As an example, the stored value 1944-06-01 12:00 UTC would previously display as 1944-06-01 13:00:00+01 if the Europe/Stockholm zone is selected, but now it will read out as 1944-06-01 14:00:00+02.

It is possible to build the time zone data files with options that will restore the older zone data, but that choice also inserts a lot of other old (and typically poorly-attested) zone data, resulting in more total changes from the previous release than accepting these upstream changes does. PostgreSQL has chosen to ship the tzdb data as-recommended, and so far as we are aware most major operating system distributions are doing likewise. However, if these changes cause significant problems for your application, a possible solution is to install a local build of the time zone data files using tzdb’s backwards-compatibility options (see their PACKRATDATA and PACKRATLIST options).