PostgreSQL

We have long required invocations of temporary functions to explicitly specify the temporary schema, that is pg_temp.`func_name(args). Require this as well for casting to temporary types using functional notation, for example `pg_temp.`type_name(arg)`. Otherwise it’s possible to capture a function call using a temporary object, allowing privilege escalation in much the same ways that we blocked in CVE-2007-2138. (CVE-2019-10208)

Hashed subplans used the outer query’s original comparison operator to compare entries of the hash table. This is the wrong thing if that operator is cross-type, since all the hash table entries will be of the subquery’s output type. For the set of hashable cross-type operators in core PostgreSQL, this mistake seems nearly harmless on 64-bit machines, but it can result in crashes or perhaps unauthorized disclosure of server memory on 32-bit machines. Extensions might provide hashable cross-type operators that create larger risks. (CVE-2019-10209)

This fixes a regression introduced in the most recent minor releases: indexes using the altered columns were not processed correctly, leading to strange failures during ALTER TABLE.

This notably applies to foreign key constraints, since those are implemented by triggers.

ALTER TABLE ... DROP COLUMN will refuse to drop a column that is a partition key column. However, indirect drops (such as a cascade from dropping a key column’s data type) had no such check, allowing the deletion of a key column. This resulted in a badly broken partitioned table that could neither be accessed nor dropped.

This fix adds pg_depend entries that enforce that the whole partitioned table, not just the key column, will be dropped if a cascaded drop forces removal of the key column. However, such entries will only be created when a partitioned table is created; so this fix does not remove the risk for pre-existing partitioned tables. The issue can only arise for partition key columns of non-built-in data types, so it seems not to be a hazard for most users.

Some operations misbehaved if the mapping wasn’t exactly one-to-one, for example if there were dropped columns in one table and not the other.

Previously an error was thrown on encountering a foreign-table partition, but that’s unhelpful and doesn’t protect against any actual problem.

Normally, if a table’s primary key column(s) are included in GROUP BY, it’s safe to drop any other grouping columns, since the primary key columns are enough to make the groups unique. This rule does not work if the query is also reading inheritance child tables, though; the parent’s uniqueness does not extend to the children.

This error resulted in duplicate result rows from some EXISTS queries.

When using a recently-created index to determine the minimum or maximum value of a column, the planner could select a recently-dead tuple that does not actually contain the endpoint value. In the worst case the tuple might contain a null, resulting in a visible error “[.quote]#found unexpected null value in index”#; more likely we would just end up using the wrong value, degrading the quality of planning estimates.

Triggers that rely on transition tables sometimes failed in the presence of concurrent updates.

ALTER TABLE could make an incorrect decision about whether revalidation of a foreign key is necessary, if not all columns of the key are of the same type. It seems likely that the error would always have been in the conservative direction, that is revalidating unnecessarily.

This avoids a “[.quote]#tuple already updated by self”# error during ANALYZE.

When two or more transactions are waiting for a transaction T1 to release a tuple-level lock, and T1 upgrades its lock to a higher level, a spurious deadlock among the waiting transactions could be reported when T1 finishes.

It is not clear whether this bug is reachable with non-artificial queries, but if it did happen, the queries involved in an otherwise-resolvable deadlock would block until canceled.

It’s incorrect to try to convert an open range to a closed one or vice versa by incrementing or decrementing the endpoint value, if the endpoint is infinite; so leave the range alone in such cases.

This avoids problems if the result is stored directly into a table.

In some corner cases, service files containing Windows-style newlines could be mis-parsed, resulting in connection failures.

If a user-defined opclass is the subtype opclass of a user-defined range type, related objects were dumped in the wrong order, producing an unrestorable dump. (The underlying failure to handle opclass dependencies might manifest in other cases too, but this is the only known case.)

This fixes build failures in some configurations.

In some cases initdb would choose one of these artificial zone names over the “[.quote]#real”# zone name. Prefer any other match to the C library’s timezone behavior over these two.

Historically, IANA set up this artificial zone with an “[.quote]#abbreviation”# like Local time zone must be set--see zic manual page. Modern versions of the tzdb database show -00 instead, but some platforms alter the data to show one or another of the historical phrases. Show this zone only if it uses the modern abbreviation.

This adds support for zic’s new -b slim option to reduce the size of the installed zone files. We are not currently using that, but may enable it in future.