The PostgreSQL Global Development Group has released an update to all supported versions of our database system, including 10.4, 9.6.9, 9.5.13, 9.4.18, 9.3.23. This release fixes one security issue as well as several bugs reported over the last three months. Users should plan to update at the next convenient downtime.
Please see the "Updating" section for post-installation steps for the security fix and the "incorrect volatility and parallel-safety markings" fix.
Please note that PostgreSQL changed its versioning scheme with the release of version 10.0, so updating to version 10.4 from 10.0, 10.1, 10.2, or 10.3 is considered a minor update.
One security vulnerability has been closed by this release:
Please see the "Updating" section below for post-update steps.
This update also fixes over 50 bugs reported in the last several months. Some of these issues affect only version 10, but many affect all supported versions.
These fixes include:
This update also contains tzdata release 2018d, with updates for Palestine and Antarctica (Casey Station), plus historical corrections for Portugal and its colonies, as well as Enderbury, Jamaica, Turks & Caicos Islands, and Uruguay.
All PostgreSQL update releases are cumulative. As with other minor releases, users are not required to dump and reload their database or use pg_upgrade to apply this update release (though for this release, please see the note about "volatility and parallel-safety markings"); you may simply shut down PostgreSQL and update its binaries.
Users who have skipped one or more update releases may need to run additional, post-update steps; please see the release notes for earlier versions for details.
If you installed "adminpack" in any PostgreSQL 9.6 or 10 release you will need to have your database administrator run the following command in every database that "adminpack" is installed in:
ALTER EXTENSION adminpack UPDATE;
Functions that should be marked "volatile"
Functions that should be marked "parallel-unsafe"
If you use any of the above functions, you can update the markings in the following ways:
Option 1: Update the markings manually in the "pg_proc" table in each database you use
these functions. You can achieve this by executing the following commands as a database superuser:
/* Functions that should be marked "volatile" */
ALTER FUNCTION pg_catalog.cursor_to_xml(refcursor, int, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.cursor_to_xmlschema(refcursor, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.query_to_xml(text, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.query_to_xml_and_xmlschema(text, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.query_to_xmlschema(text, boolean, boolean, text) VOLATILE;
/* Functions that should be marked "parallel-unsafe" */
ALTER FUNCTION pg_catalog.binary_upgrade_create_empty_extension(text, text, bool, text, _oid, _text, _text) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.brin_desummarize_range(regclass, bigint) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.brin_summarize_new_values(regclass) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.brin_summarize_range(regclass, bigint) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.cursor_to_xml(refcursor, int, boolean, boolean, text) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.cursor_to_xmlschema(refcursor, boolean, boolean, text) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.gin_clean_pending_list(regclass) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.pg_import_system_collations(regnamespace) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.ts_rewrite(tsquery, text) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.ts_stat(text) PARALLEL UNSAFE;
ALTER FUNCTION pg_catalog.ts_stat(text, text) PARALLEL UNSAFE;
Option 2: Run a pg_upgrade to a version containing the correct marking data (e.g. 10.4 and above)