↑↓ select ↵ open ⌫ change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

DocumentationVersion comparison

POSTGRESQL · VERSION COMPARE

PostgreSQL 9.5.9 release changes

All features, fixes, and compatibility notes in this release, with related records from other versions.

All changes in this release
All changes in this release

Includes changes after the source version through the target. A major version name means its initial release.

From PostgreSQL 9.0 onward: 17 major branches and 352 release notes. Updated 2026-09-26.

Complete release changes

9.5.9

2017-08-31

Export JSON
8changesFeatures, fixes, improvements
1releaseGrouped by release
0CVEsVulnerability IDs mentioned in these notes

9.5.9 HistoricalSupport ends 2021-02-11

PostgreSQL 9.5.9

Migration and compatibility

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

However, if you are upgrading from a version earlier than 9.5.8, see Section E.18.

ImprovementsShow foreign tables in information_schema.table_privileges view

Changes

Show foreign tables in information_schema.table_privileges view (Peter Eisentraut)

All other relevant information_schema views include foreign tables, but this one ignored them.

Since this view definition is installed by initdb, merely upgrading will not fix the problem. If you need to fix this in an existing installation, you can, as a superuser, do this in psql:

SET search_path TO information_schema;
CREATE OR REPLACE VIEW table_privileges AS
    SELECT CAST(u_grantor.rolname AS sql_identifier) AS grantor,
           CAST(grantee.rolname AS sql_identifier) AS grantee,
           CAST(current_database() AS sql_identifier) AS table_catalog,
           CAST(nc.nspname AS sql_identifier) AS table_schema,
           CAST(c.relname AS sql_identifier) AS table_name,
           CAST(c.prtype AS character_data) AS privilege_type,
           CAST(
             CASE WHEN
                  -- object owner always has grant options
                  pg_has_role(grantee.oid, c.relowner, 'USAGE')
                  OR c.grantable
                  THEN 'YES' ELSE 'NO' END AS yes_or_no) AS is_grantable,
           CAST(CASE WHEN c.prtype = 'SELECT' THEN 'YES' ELSE 'NO' END AS yes_or_no) AS with_hierarchy

    FROM (
            SELECT oid, relname, relnamespace, relkind, relowner, (aclexplode(coalesce(relacl, acldefault('r', relowner)))).* FROM pg_class
         ) AS c (oid, relname, relnamespace, relkind, relowner, grantor, grantee, prtype, grantable),
         pg_namespace nc,
         pg_authid u_grantor,
         (
           SELECT oid, rolname FROM pg_authid
           UNION ALL
           SELECT 0::oid, 'PUBLIC'
         ) AS grantee (oid, rolname)

    WHERE c.relnamespace = nc.oid
          AND c.relkind IN ('r', 'v', 'f')
          AND c.grantee = grantee.oid
          AND c.grantor = u_grantor.oid
          AND c.prtype IN ('INSERT', 'SELECT', 'UPDATE', 'DELETE', 'TRUNCATE', 'REFERENCES', 'TRIGGER')
          AND (pg_has_role(u_grantor.oid, 'USAGE')
               OR pg_has_role(grantee.oid, 'USAGE')
               OR grantee.rolname = 'PUBLIC');

This must be repeated in each database to be fixed, including template0.

Related records (4)

“Same change” requires complete matching evidence. “Related commits” can cover independent changes, a partial backport, or a follow-up correction; each release keeps its own explanation.

ImprovementsClean up handling of a fatal exit (e.g., due to receipt of SIGTERM) that occurs while trying to execute a ROLLBACK of a failed transaction

Changes

Clean up handling of a fatal exit (e.g., due to receipt of SIGTERM) that occurs while trying to execute a ROLLBACK of a failed transaction (Tom Lane)

This situation could result in an assertion failure. In production builds, the exit would still occur, but it would log an unexpected message about "cannot drop active portal".

Related records (4)

“Same change” requires complete matching evidence. “Related commits” can cover independent changes, a partial backport, or a follow-up correction; each release keeps its own explanation.

ImprovementsRemove assertion that could trigger during a fatal exit

Changes

Remove assertion that could trigger during a fatal exit (Tom Lane)

Related records (4)

“Same change” requires complete matching evidence. “Related commits” can cover independent changes, a partial backport, or a follow-up correction; each release keeps its own explanation.

ImprovementsCorrectly identify columns that are of a range type or domain type over a composite type or domain type being searched for

Changes

Correctly identify columns that are of a range type or domain type over a composite type or domain type being searched for (Tom Lane)

Certain ALTER commands that change the definition of a composite type or domain type are supposed to fail if there are any stored values of that type in the database, because they lack the infrastructure needed to update or check such values. Previously, these checks could miss relevant values that are wrapped inside range types or sub-domains, possibly allowing the database to become inconsistent.

Related records (4)

“Same change” requires complete matching evidence. “Related commits” can cover independent changes, a partial backport, or a follow-up correction; each release keeps its own explanation.

Bug fixesFix crash in pg_restore when using parallel mode and using a list file to select a subset of items to restore

Changes

Fix crash in pg_restore when using parallel mode and using a list file to select a subset of items to restore (Fabrízio de Royes Mello)

Related records (3)

“Same change” requires complete matching evidence. “Related commits” can cover independent changes, a partial backport, or a follow-up correction; each release keeps its own explanation.

ImprovementsChange ecpg's parser to allow RETURNING clauses without attached C variables

Changes

Change ecpg's parser to allow RETURNING clauses without attached C variables (Michael Meskes)

This allows ecpg programs to contain SQL constructs that use RETURNING internally (for example, inside a CTE) rather than using it to define values to be returned to the client.

Related records (4)

“Same change” requires complete matching evidence. “Related commits” can cover independent changes, a partial backport, or a follow-up correction; each release keeps its own explanation.

ImprovementsImprove selection of compiler flags for PL/Perl on Windows

Changes

Improve selection of compiler flags for PL/Perl on Windows (Tom Lane)

This fix avoids possible crashes of PL/Perl due to inconsistent assumptions about the width of time_t values. A side-effect that may be visible to extension developers is that _USE_32BIT_TIME_T is no longer defined globally in PostgreSQL Windows builds. This is not expected to cause problems, because type time_t is not used in any PostgreSQL API definitions.

Related records (4)

“Same change” requires complete matching evidence. “Related commits” can cover independent changes, a partial backport, or a follow-up correction; each release keeps its own explanation.

Bug fixesFix make check to behave correctly when invoked via a non-GNU make program

Changes

Fix make check to behave correctly when invoked via a non-GNU make program (Thomas Munro)

Related records (1)

“Same change” requires complete matching evidence. “Related commits” can cover independent changes, a partial backport, or a follow-up correction; each release keeps its own explanation.

How is this comparison generated?

The comparison follows PostgreSQL release notes from just after the source through the target version. For a major upgrade, maintenance releases from each older branch are included only up to the next major release date, and never after the target date. A major version such as 18 means its initial release, 18.0. Previews and development snapshots are labeled separately.

Entries come from the original English manuals. Release coverage and commit evidence are verified against upstream sources. Every entry retains its complete explanation and source link. Categories aid browsing; read the full notes for impact, conditions, and migration steps.

Fixes can be backported to several branches. Confirmed duplicates are merged conservatively, with every branch explanation retained. A note describing several independent fixes is excluded only when all are already present in the source. Major-release features remain distinct from related maintenance patches unless their complete original descriptions match. Uncertain matches are retained. This is a release-note history, not an exhaustive comparison of compiled binaries.

CVE results are calculated independently from the PostgreSQL security registry and vulnerability records. A CVE counts as gained protection only when the source is affected and the target is fixed or unaffected. Remaining vulnerabilities are listed separately. Security entries and distinct CVEs are counted separately.

Interaction inspired by pgversions.com and pgversionreport. Content comes from PostgreSQL release notes. See the release notes archive.