PostgreSQL

An unprivileged user of dblink or postgres_fdw could bypass the checks intended to prevent use of server-side credentials, such as a ~/.pgpass file owned by the operating-system user running the server. Servers allowing peer authentication on local connections are particularly vulnerable. Other attacks such as SQL injection into a postgres_fdw session are also possible. Attacking postgres_fdw in this way requires the ability to create a foreign server object with selected connection parameters, but any user with access to dblink could exploit the problem. In general, an attacker with the ability to select the connection parameters for a libpq-using application could cause mischief, though other plausible attack scenarios are harder to think of. Our thanks to Andrew Krasichkov for reporting this issue. (CVE-2018-10915)

Erroneous expansion of an updatable view could lead to crashes or “[.quote]#attribute …​ has the wrong type”# errors, if the view’s SELECT list doesn’t match one-to-one with the underlying table’s columns. Furthermore, this bug could be leveraged to allow updates of columns that an attacking user lacks UPDATE privilege for, if that user has INSERT and UPDATE privileges for some other column(s) of the table. Any user could also use it for disclosure of server memory. (CVE-2018-10925)

Overoptimistic caching rules could prevent these updates from being seen by other sessions, leading to spurious errors and/or data corruption. The problem was significantly worse for shared catalogs, such as pg_authid, because the stale cache data could persist into new sessions as well as existing ones.

This led to a situation where the server did not think it had reached a consistent database state during subsequent WAL replay, preventing restart.

This mistake has been seen to cause assertion failures, and potentially it could result in unnecessary query cancellations on hot standby servers.

Treat such a case as corrupt data. Previously, the code would try to allocate space and get a hard error, making recovery impossible.

This avoids some situations where a failure during recovery cleanup (such as a problem with a two-phase state file) led to inconsistent timeline state on-disk.

This change reduces the number of times that shared buffers are scanned, so that it is of most benefit when that setting is large.

The code previously mis-detected whether or not it had caught up with the upstream server.

This omission led to failures in some cases, such as domains with constraints using SQL-language functions.

Previously, table synchronization could misbehave if any subtransactions were aborted after modifying a table being synchronized.

Previously, the failed index’s OID could remain in the list, causing problems later in the same session.

This could result in an assertion failure after pg_upgrade of a pre-9.4 GIN index (9.4 and later will not create such pages).

This reduces contention on many-CPU systems, fixing a performance regression (compared to previous releases) on Linux and FreeBSD.

Previously, parallel workers could get stuck waiting for a lock on an index page, and not notice requests to abort the query.

Corrupted btree indexes could result in an infinite loop here, and that previously wasn’t interruptible without forcing a crash.

This could lead to bad plan choices in situations where that optimization was applicable.

This resulted in failure to recognize that an index on a composite column could provide the sort order needed for a mergejoin on that column.

While previously allowed, this case didn’t work reliably.

Names of collations, conversions, text search objects, publication relations, and extended statistics objects were not schema-qualified when they should be.

This avoids two problems with input exceeding 4G lines: COPY FROM WITH HEADER would drop a line every 4G lines, not only the first line, and error reports could show a wrong line number.

This use-case was accidentally broken in release 10.0.

Under rare circumstances, this oversight could result in “[.quote]#could not generate random cancel key”# failures that could only be resolved by restarting the postmaster.

PQhost() gave misleading or incorrect results in some cases. Now, it uniformly returns the host name if specified, or the host address if only that is specified, or the default host name (typically /tmp or localhost) if both parameters are omitted.

Also, the wrong value might be compared to the server name when verifying an SSL certificate.

Also, the wrong value might be compared to the host name field in ~/.pgpass. Now, that field is compared to the host name if specified, or the host address if only that is specified, or localhost if both parameters are omitted.

Also, an incorrect error message was reported for an unparseable hostaddr value.

Also, when the host, hostaddr, or port parameters contain comma-separated lists, libpq is now more careful to treat empty elements of a list as selecting the default behavior.

On Windows, crashes can ensue if the free call for a given chunk of memory is not made from the same DLL that malloc’ed the memory. The `pgtypes library sometimes returns strings that it expects the caller to free, making it impossible to follow this rule. Add a PGTYPESchar_free() function that just wraps free, allowing applications to follow this rule.

This error led to assertion failures, or in rare cases, failure to enforce the INTO STRICT option as expected.

The previous fix for quoting of search_path and other list-valued variables in pg_dump output turned out to misbehave for empty-string list elements, and it risked truncation of long file paths.

Manually created unique indexes were properly marked, but not those created by declaring UNIQUE or PRIMARY KEY constraints.

The previous check could be fooled by an immediate-mode shutdown.

This avoids problems when building on platforms that supply old copies of PostgreSQL libraries.

This update includes a redefinition of “[.quote]#daylight savings”# in Ireland, as well as for some past years in Namibia and Czechoslovakia. In those jurisdictions, legally standard time is observed in summer, and daylight savings time in winter, so that the daylight savings offset is one hour behind standard time not one hour ahead. This does not affect either the actual UTC offset or the timezone abbreviations in use; the only known effect is that the is_dst column in the pg_timezone_names view will now be true in winter and false in summer in these cases.