PostgreSQL

pg_logfile_rotate() is a deprecated wrapper for the core function pg_rotate_logfile(). When that function was changed to rely on SQL privileges for access control rather than a hard-coded superuser check, pg_logfile_rotate() should have been updated as well, but the need for this was missed. Hence, if adminpack is installed, any user could request a logfile rotation, creating a minor security issue.

After installing this update, administrators should update adminpack by performing ALTER EXTENSION adminpack UPDATE in each database in which adminpack is installed. (CVE-2018-1115)

The functions query_to_xml, cursor_to_xml, cursor_to_xmlschema, query_to_xmlschema, and query_to_xml_and_xmlschema should be marked volatile because they execute user-supplied queries that might contain volatile operations. They were not, leading to a risk of incorrect query optimization. This has been repaired for new installations by correcting the initial catalog data, but existing installations will continue to contain the incorrect markings. Practical use of these functions seems to pose little hazard, but in case of trouble, it can be fixed by manually updating these functions' pg_proc entries, for example ALTER FUNCTION pg_catalog.query_to_xml(text, boolean, boolean, text) VOLATILE. (Note that that will need to be done in each database of the installation.) Another option is to pg_upgrade the database to a version containing the corrected initial data.

The functions brin_summarize_new_values, brin_summarize_range, brin_desummarize_range, gin_clean_pending_list, cursor_to_xml, cursor_to_xmlschema, ts_rewrite, ts_stat, binary_upgrade_create_empty_extension, and pg_import_system_collations should be marked parallel-unsafe; some because they perform database modifications directly, and others because they execute user-supplied queries that might do so. They were marked parallel-restricted instead, leading to a risk of unexpected query errors. This has been repaired for new installations by correcting the initial catalog data, but existing installations will continue to contain the incorrect markings. Practical use of these functions seems to pose little hazard unless force_parallel_mode is turned on. In case of trouble, it can be fixed by manually updating these functions' pg_proc entries, for example ALTER FUNCTION pg_catalog.brin_summarize_new_values(regclass) PARALLEL UNSAFE. (Note that that will need to be done in each database of the installation.) Another option is to pg_upgrade the database to a version containing the corrected initial data.

Once the OID counter has wrapped around, it’s possible to assign a TOAST value whose OID matches a previously deleted entry in the same TOAST table. If that entry were not yet vacuumed away, this resulted in “[.quote]#unexpected chunk number 0 (expected 1) for toast value `nnnnn”# errors, which would persist until the dead entry was removed by `VACUUM. Fix by not selecting such OIDs when creating a new TOAST entry.

Previously, only constraints declared for the partitioned table as a whole were checked.

Previously, only string-literal values were accepted for a boolean partitioning column. But then pg_dump would print such values as TRUE or FALSE, leading to dump/reload failures.

This error could lead to crashes when using user-defined operator classes for partition keys.

Previously, pages not actually scanned by ANALYZE were assumed to retain their old tuple density. In a large table where ANALYZE samples only a small fraction of the pages, this meant that the overall tuple density estimate could not change very much, so that reltuples would change nearly proportionally to changes in the table’s physical size (relpages) regardless of what was actually happening in the table. This has been observed to result in reltuples becoming so much larger than reality as to effectively shut off autovacuuming. To fix, assume that `ANALYZE’s sample is a statistically unbiased sample of the table (as it should be), and just extrapolate the density observed within those pages to the whole table.

Also add an INCLUDING STATISTICS option, to allow finer-grained control over whether this happens.

On platforms where long is 32 bits (which includes 64-bit Windows as well as most 32-bit machines), copied sequence parameters would be truncated to 32 bits.

This error could result in misclassifying a condition as a “[.quote]#join filter”# for an outer join when it should be a plain “[.quote]#filter”# condition, leading to incorrect join output.

This could, for example, allow constraint exclusion to exclude a child table that should not be excluded from a query.

This could happen if some tuples were locked (but not deleted). While queries would still function correctly, vacuum would normally ignore such pages, with the long-term effect that the tuples were never frozen. In recent releases this would eventually result in errors such as “[.quote]#found multixact `nnnnn from before relminmxid nnnnn`”#.

This could result in incorrect “[.quote]#cannot freeze committed xmax”# failures in databases that have been pg_upgrade’d from 9.2 or earlier.

The previous behavior caused drastic loss of potential worker concurrency in databases with many tables.

Previously the supposedly-local snapshot contained a pointer into shared memory, allowing the client hostname column to change unexpectedly if any existing session disconnected.

The application_name, client_hostname, and query fields might show incorrect data for such processes.

Such searches would return the wrong set of rows in most non-C locales.

Previously, the tuple count was reported to be the same as that of the underlying table, which is wrong if the index is partial.

Previously it reported the estimated number of heap tuples, which might be inaccurate, and is certainly wrong if the index is partial.

Discard the previous output before, not after, processing the error message. On some platforms, notably Linux, this can make a difference in the application’s subsequent memory footprint.

The local_preload_libraries, session_preload_libraries, shared_preload_libraries, and temp_tablespaces variables were not correctly quoted in pg_dump output. This would cause problems if settings for these variables appeared in CREATE FUNCTION ... SET or ALTER DATABASE/ROLE ... SET clauses.

A previous fix caused pg_recvlogical to issue a command regardless of server version, but it should only be issued to v10 and later servers.

Failure to do this could result in data inconsistency on the target, particularly if the file in question is a WAL segment.

The previous coding failed to detect overflow of the loop variable on some non-gcc compilers, leading to an infinite loop.

Fix possible omission of the table’s last tuple from the index. Count the number of index tuples correctly, in case it is a partial index.

This fixes the zic timezone data compiler to cope with negative daylight-savings offsets. While the PostgreSQL project will not immediately ship such timezone data, zic might be used with timezone data obtained directly from IANA, so it seems prudent to update zic now.