PostgreSQL

This error led to crashes or, with carefully crafted input, disclosure of arbitrary backend memory. (CVE-2018-1052)

pg_upgrade normally restricts its temporary files to be readable and writable only by the calling user. But the temporary file containing pg_dumpall -g output would be group- or world-readable, or even writable, if the user’s umask setting allows. In typical usage on multi-user machines, the umask and/or the working directory’s permissions would be tight enough to prevent problems; but there may be people using pg_upgrade in scenarios where this oversight would permit disclosure of database passwords to unfriendly eyes. (CVE-2018-1053)

In some cases VACUUM would fail to remove such tuples even though they are now dead, leading to assorted data corruption scenarios.

This is necessary to ensure that dead index entries get removed. The old code got it backwards, allowing vacuum to skip the cleanup if some other process were running cleanup concurrently, thus risking invalid entries being left behind in the index.

These errors could result in misbehavior under concurrent load. The potential consequences have not been characterized fully.

This prevents poor behavior when rebuilding hash indexes on the table, since those use the pg_class statistics to govern the initial hash size.

These cases will be treated as unsupported features for now.

In several contexts, notably COPY and ALTER TABLE ADD COLUMN, the expected default value was not applied and instead a null value was inserted.

A mix of regular and foreign tables in an inheritance tree resulted in creation of incorrect plans for UPDATE and DELETE queries. This led to visible failures in some cases, notably when there are row-level triggers on a foreign child table.

Previously, although extended statistics could be declared and collected on boolean columns, the planner failed to apply them.

Cases similar to SELECT DISTINCT unnest(foo) got a lower output rowcount estimate in 10.0 than they did in earlier releases, possibly resulting in unfavorable plan choices. Restore the prior estimation behavior.

Logical decoding may spill WAL records to disk for transactions generating many WAL records. Normally these files are cleaned up after the transaction’s commit or abort record arrives; but if no such record is ever seen, the removal code misbehaved.

Previously this was printed as scram-sha256, possibly confusing users as to the correct spelling.

We always store XML strings in the database encoding, so allowing libxml to act on a declaration of another encoding gave wrong results. In encodings other than UTF8, we don’t promise to support non-ASCII XML data anyway, so retain the previous behavior for bug compatibility. This change affects only xpath() and related functions; other XML code paths already acted this way.

Up to now, PostgreSQL servers simply rejected requests to use protocol versions newer than 3.0, so that there was no functional difference between the major and minor parts of the protocol version number. Allow clients to request versions 3.x without failing, sending back a message showing that the server only understands 3.0. This makes no difference at the moment, but back-patching this change should allow speedier introduction of future minor protocol upgrades.

v10 does not have this feature, and the connection-time negotiation about whether to use it was done incorrectly.

Given repeatedly-unlucky timing, a process attempting to awaken all waiters for a condition variable could loop indefinitely. Due to the limited usage of condition variables in v10, this affects only parallel index scans and some operations on replication slots.

Parallel query previously tended to hang indefinitely if a worker could not be started, as the result of fork() failure or other low-probability problems.

This prevents emitting garbage in postmaster log output from such workers.

Typically, compilers assume that __int128 variables are aligned on 16-byte boundaries, but our memory allocation infrastructure isn’t prepared to guarantee that, and increasing the setting of MAXALIGN seems infeasible for multiple reasons. Adjust the code to allow use of __int128 only when we can tell the compiler to assume lesser alignment. The only known symptom of this problem so far is crashes in some parallel aggregation queries.

This could only happen during an update or SELECT FOR UPDATE of a join, when there is a concurrent update of some selected row.

These functions are stated to be Oracle##® compatible, but they weren’t exactly. In particular, there was a discrepancy in the interpretation of a negative third parameter: Oracle thinks that a negative value indicates the last place where the target substring can begin, whereas our functions took it as the last place where the target can end. Also, Oracle throws an error for a zero or negative fourth parameter, whereas our functions returned zero.

The sample code has been adjusted to match Oracle’s behavior more precisely. Users who have copied this code into their applications may wish to update their copies.

The “[.quote]#tag”# portion of an ACL archive entry was usually just the name of the associated object. Make it start with the object type instead, bringing ACLs into line with the convention already used for comment and security label archive entries. Also, fix the comment and security label entries for the whole database, if present, to make their tags start with DATABASE so that they also follow this convention. This prevents false matches in code that tries to identify large-object-related entries by seeing if the tag starts with LARGE OBJECT. That could have resulted in misclassifying entries as data rather than schema, with undesirable results in a schema-only or data-only dump.

Note that this change has user-visible results in the output of pg_restore --list.

This change prevents build failures with newer glibc versions.

The meaning of the second argument (the dimension selector) has been changed to make it predictable which value is selected even when dealing with cubes of varying dimensionalities.

This is an incompatible change, but since the point of the operator was to be used in KNN searches, it seems rather useless as-is. After installing this update, any expression indexes or materialized views using this operator will need to be reindexed/refreshed.

The scripts in contrib/start-scripts/osx use infrastructure that’s been deprecated for over a decade, and which no longer works at all in macOS releases of the last couple of years. Add a new subdirectory contrib/start-scripts/macos containing scripts that use the newer launchd infrastructure.

This allows building PL/Perl with some common Perl distributions for Windows.

Available Perl distributions are inconsistent about what they expect, and lack any reliable means of reporting it, so resort to a build-time test on what the library being used actually does.

This may allow collection of a core dump for some early-startup failures that did not produce a dump before.