## E.50. Release 9.2.21

Release date: 2017-05-11

This release contains a variety of fixes from 9.2.20. For information about new features in the 9.2 major release, see Section E.71, “Release 9.2”.

The PostgreSQL community will stop releasing updates for the 9.2.X release series in September 2017. Users are encouraged to update to a newer release branch soon.

### E.50.1. Migration to Version 9.2.21

A dump/restore is not required for those running 9.2.X.

However, if you use foreign data servers that make use of user passwords for authentication, see the first changelog entry below.

Also, if you are upgrading from a version earlier than 9.2.20, see Section E.51, “Release 9.2.20”.

### E.50.2. Changes

- Restrict visibility of `pg_user_mappings`.`umoptions`, to protect passwords stored as user mapping options (Michael Paquier, Feike Steenbergen)

  The previous coding allowed the owner of a foreign server object, or anyone he has granted server `USAGE` permission to, to see the options for all user mappings associated with that server. This might well include passwords for other users. Adjust the view definition to match the behavior of `information_schema.user_mapping_options`, namely that these options are visible to the user being mapped, or if the mapping is for `PUBLIC` and the current user is the server owner, or if the current user is a superuser. (CVE-2017-7486)

  By itself, this patch will only fix the behavior in newly initdb'd databases. If you wish to apply this change in an existing database, you will need to do the following:

  1. Restart the postmaster after adding `allow_system_table_mods = true` to `postgresql.conf`. (In versions supporting `ALTER SYSTEM`, you can use that to make the configuration change, but you'll still need a restart.)

  2. In each database of the cluster, run the following commands as superuser:

         SET search_path = pg_catalog;
         CREATE OR REPLACE VIEW pg_user_mappings AS
             SELECT
                 U.oid       AS umid,
                 S.oid       AS srvid,
                 S.srvname   AS srvname,
                 U.umuser    AS umuser,
                 CASE WHEN U.umuser = 0 THEN
                     'public'
                 ELSE
                     A.rolname
                 END AS usename,
                 CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
                             OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
                             OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
                             THEN U.umoptions
                          ELSE NULL END AS umoptions
             FROM pg_user_mapping U
                  LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
                 pg_foreign_server S ON (U.umserver = S.oid);

  3. Do not forget to include the `template0` and `template1` databases, or the vulnerability will still exist in databases you create later. To fix `template0`, you'll need to temporarily make it accept connections. In PostgreSQL 9.5 and later, you can use

         ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;

     and then after fixing `template0`, undo that with

         ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;

     In prior versions, instead use

         UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
         UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

  4. Finally, remove the `allow_system_table_mods` configuration setting, and again restart the postmaster.

- Prevent exposure of statistical information via leaky operators (Peter Eisentraut)

  Some selectivity estimation functions in the planner will apply user-defined operators to values obtained from `pg_statistic`, such as most common values and histogram entries. This occurs before table permissions are checked, so a nefarious user could exploit the behavior to obtain these values for table columns he does not have permission to read. To fix, fall back to a default estimate if the operator's implementation function is not certified leak-proof and the calling user does not have permission to read the table column whose statistics are needed. At least one of these criteria is satisfied in most cases in practice. (CVE-2017-7484)

- Fix possible corruption of “init forks” of unlogged indexes (Robert Haas, Michael Paquier)

  This could result in an unlogged index being set to an invalid state after a crash and restart. Such a problem would persist until the index was dropped and rebuilt.

- Fix incorrect reconstruction of `pg_subtrans` entries when a standby server replays a prepared but uncommitted two-phase transaction (Tom Lane)

  In most cases this turned out to have no visible ill effects, but in corner cases it could result in circular references in `pg_subtrans`, potentially causing infinite loops in queries that examine rows modified by the two-phase transaction.

- Ensure parsing of queries in extension scripts sees the results of immediately-preceding DDL (Julien Rouhaud, Tom Lane)

  Due to lack of a cache flush step between commands in an extension script file, non-utility queries might not see the effects of an immediately preceding catalog change, such as `ALTER TABLE ... RENAME`.

- Skip tablespace privilege checks when `ALTER TABLE ... ALTER COLUMN TYPE` rebuilds an existing index (Noah Misch)

  The command failed if the calling user did not currently have `CREATE` privilege for the tablespace containing the index. That behavior seems unhelpful, so skip the check, allowing the index to be rebuilt where it is.

- Fix `ALTER TABLE ... VALIDATE CONSTRAINT` to not recurse to child tables when the constraint is marked `NO INHERIT` (Amit Langote)

  This fix prevents unwanted “constraint does not exist” failures when no matching constraint is present in the child tables.

- Fix `VACUUM` to account properly for pages that could not be scanned due to conflicting page pins (Andrew Gierth)

  This tended to lead to underestimation of the number of tuples in the table. In the worst case of a small heavily-contended table, `VACUUM` could incorrectly report that the table contained no tuples, leading to very bad planning choices.

- Ensure that bulk-tuple-transfer loops within a hash join are interruptible by query cancel requests (Tom Lane, Thomas Munro)

- Fix `cursor_to_xml()` to produce valid output with `tableforest` = false (Thomas Munro, Peter Eisentraut)

  Previously it failed to produce a wrapping `<table>` element.

- Improve performance of `pg_timezone_names` view (Tom Lane, David Rowley)

- Fix sloppy handling of corner-case errors from `lseek()` and `close()` (Tom Lane)

  Neither of these system calls are likely to fail in typical situations, but if they did, `fd.c` could get quite confused.

- Fix incorrect check for whether postmaster is running as a Windows service (Michael Paquier)

  This could result in attempting to write to the event log when that isn't accessible, so that no logging happens at all.

- Fix ecpg to support `COMMIT PREPARED` and `ROLLBACK PREPARED` (Masahiko Sawada)

- Fix a double-free error when processing dollar-quoted string literals in ecpg (Michael Meskes)

- In pg_dump, fix incorrect schema and owner marking for comments and security labels of some types of database objects (Giuseppe Broccolo, Tom Lane)

  In simple cases this caused no ill effects; but for example, a schema-selective restore might omit comments it should include, because they were not marked as belonging to the schema of their associated object.

- Avoid emitting an invalid list file in `pg_restore -l` when SQL object names contain newlines (Tom Lane)

  Replace newlines by spaces, which is sufficient to make the output valid for `pg_restore -L`'s purposes.

- Fix pg_upgrade to transfer comments and security labels attached to “large objects” (blobs) (Stephen Frost)

  Previously, blobs were correctly transferred to the new database, but any comments or security labels attached to them were lost.

- Improve error handling in `contrib/adminpack`'s `pg_file_write()` function (Noah Misch)

  Notably, it failed to detect errors reported by `fclose()`.

- In `contrib/dblink`, avoid leaking the previous unnamed connection when establishing a new unnamed connection (Joe Conway)

- Support OpenSSL 1.1.0 (Heikki Linnakangas, Andreas Karlsson, Tom Lane)

  This is a back-patch of work previously done in newer branches; it's needed since many platforms are adopting newer OpenSSL versions.

- Support Tcl 8.6 in MSVC builds (Álvaro Herrera)

- Sync our copy of the timezone library with IANA release tzcode2017b (Tom Lane)

  This fixes a bug affecting some DST transitions in January 2038.

- Update time zone data files to tzdata release 2017b for DST law changes in Chile, Haiti, and Mongolia, plus historical corrections for Ecuador, Kazakhstan, Liberia, and Spain. Switch to numeric abbreviations for numerous time zones in South America, the Pacific and Indian oceans, and some Asian and Middle Eastern countries.

  The IANA time zone database previously provided textual abbreviations for all time zones, sometimes making up abbreviations that have little or no currency among the local population. They are in process of reversing that policy in favor of using numeric UTC offsets in zones where there is no evidence of real-world use of an English abbreviation. At least for the time being, PostgreSQL will continue to accept such removed abbreviations for timestamp input. But they will not be shown in the `pg_timezone_names` view nor used for output.

- Use correct daylight-savings rules for POSIX-style time zone names in MSVC builds (David Rowley)

  The Microsoft MSVC build scripts neglected to install the `posixrules` file in the timezone directory tree. This resulted in the timezone code falling back to its built-in rule about what DST behavior to assume for a POSIX-style time zone name. For historical reasons that still corresponds to the DST rules the USA was using before 2007 (i.e., change on first Sunday in April and last Sunday in October). With this fix, a POSIX-style zone name will use the current and historical DST transition dates of the `US/Eastern` zone. If you don't want that, remove the `posixrules` file, or replace it with a copy of some other zone file (see Section 8.5.3, “Time Zones”). Note that due to caching, you may need to restart the server to get such changes to take effect.