PostgreSQL

Some of the planner’s selectivity estimators apply user-defined operators to values found in pg_statistic (e.g., most-common values). A leaky operator therefore can disclose some of the entries in a data column, even if the calling user lacks permission to read that column. In CVE-2017-7484 we added restrictions to forestall that, but we failed to consider the effects of row-level security. A user who has SQL permission to read a column, but who is forbidden to see certain rows due to RLS policy, might still learn something about those rows' contents via a leaky operator. This patch further tightens the rules, allowing leaky operators to be applied to statistics data only when there is no relevant RLS policy. (CVE-2019-10130)

This hazard was overlooked because the case is not actually useful, since the temporary table would be dropped immediately after creation.

This occurs when using READ COMMITTED isolation level and another session has concurrently updated some of the target row(s).

In such cases, the query did not report the correct set of output columns when a RETURNING clause was present, and if there were any statement-level triggers that should be fired, it didn’t fire them.

Such tables should be ignored for publication purposes, but some parts of the code failed to do so.

When the updatable view has no default for the column but its underlying table has one, a single-row INSERT ... VALUES will use the underlying table’s default. In the multi-row case, however, NULL was always used. Correct it to act like the single-row case.

We should allow this for consistency with allowing zero-column tables. Since a table can be converted to a view, zero-column views could be created even with the restriction in place, leading to dump/reload failures.

The combination of IF NOT EXISTS and EXECUTE should work, but the grammar omitted it.

Previously, if the table having the RLS policy was accessed via a view, such checks might be executed as the user calling the view, not as the view owner as they should be.

Previously PostgreSQL followed the SQL:2003 definition, which doesn’t allow this. But that creates a serious problem for dump/restore: there is no setting of xmloption that will accept all valid XML data. Hence, switch to the 2006 definition.

pg_dump is also modified to emit SET xmloption = content while restoring data, ensuring that dump/restore works even if the prevailing setting is document.

The postmaster is now more likely to detect that there are still active processes from a previous postmaster incarnation, even if the postmaster.pid file has been removed.

A fix applied in February’s minor releases was not sufficiently careful about backwards compatibility, leading to problems if a standby server of that vintage reads GIN page-deletion WAL records generated by a primary server of a previous minor release.

The previous change to panic on file synchronization failures turns out to have been excessively paranoid for certain cases where a failure is predictable and essentially means “[.quote]#operation not supported”#.

In v10, this oversight only led to slightly inefficient plans, but in v11 it could cause “[.quote]#set-valued function called in context that cannot accept a set”# errors.

When an underlying table is being accessed via a view, consider the privileges of the view owner while deciding whether leaky operators may be applied to the table’s statistics data, rather than the privileges of the user making the query. This makes the planner’s rules about what data is visible match up with the executor’s, avoiding unnecessarily-poor plans.

These could lead to “[.quote]#dsa_area could not attach to segment”# or “[.quote]#cannot unpin a segment that is not pinned”# errors.

A password string that had the right initial characters could be mistaken for one that is correctly hashed into SCRAM-SHA-256 or MD5 format. The password would be accepted but would be unusable later.

Localized month or day names that include non-ASCII characters previously caused unexpected errors or wrong output in such locales.

No core code cares about this, but some extensions do.

A previously unrecognized source of these failures is creation of thread stacks for a process’s default thread pool. Arrange for such stacks to be allocated in a different memory region.

Errors, such as lack of permissions to read the directory, were not detected or reported correctly; instead the code silently acted as though the directory were empty.

A missing semicolon led to mistranslation of SET +`_`+variable`+ = DEFAULT+` (but not SET +`_`+variable`+ TO DEFAULT+) in ecpg programs, producing syntactically invalid output that the server would reject. Additionally, in a `DROP TYPE or DROP DOMAIN command that listed multiple type names, only the first type name was actually processed.

This corrects a small bug in zic that caused it to output an incorrect year-2440 transition in the Africa/Casablanca zone, and adds support for zic’s new -r option.

Etc/UCT is now a backward-compatibility link to Etc/UTC, instead of being a separate zone that generates the abbreviation UCT, which nowadays is typically a typo. PostgreSQL will still accept UCT as an input zone abbreviation, but it won’t output it.