↑↓ 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.4.10 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.4.10

2016-10-27

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

9.4.10 HistoricalSupport ends 2020-02-13

PostgreSQL 9.4.10

Migration and compatibility

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

However, if your installation has been affected by the bug described in the first changelog entry below, then after updating you may need to take action to repair corrupted free space maps.

Also, if you are upgrading from a version earlier than 9.4.6, see Section E.21.

Bug fixesFix WAL-logging of truncation of relation free space maps and visibility maps

Changes

Fix WAL-logging of truncation of relation free space maps and visibility maps (Pavan Deolasee, Heikki Linnakangas)

It was possible for these files to not be correctly restored during crash recovery, or to be written incorrectly on a standby server. Bogus entries in a free space map could lead to attempts to access pages that have been truncated away from the relation itself, typically producing errors like "could not read block XXX: read only 0 of 8192 bytes". Checksum failures in the visibility map are also possible, if checksumming is enabled.

Procedures for determining whether there is a problem and repairing it if so are discussed at https://wiki.postgresql.org/wiki/Free_Space_Map_Problems.

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.

Bug fixesFix incorrect creation of GIN index WAL records on big-endian machines

Changes

Fix incorrect creation of GIN index WAL records on big-endian machines (Tom Lane)

The typical symptom was "unexpected GIN leaf action" errors during WAL replay.

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.

Bug fixesFix SELECT FOR UPDATE/SHARE to correctly lock tuples that have been updated by a subsequently-aborted transaction

Changes

Fix SELECT FOR UPDATE/SHARE to correctly lock tuples that have been updated by a subsequently-aborted transaction (Álvaro Herrera)

In 9.5 and later, the SELECT would sometimes fail to return such tuples at all. A failure has not been proven to occur in earlier releases, but might be possible with concurrent updates.

Related records (2)

“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 EvalPlanQual rechecks involving CTE scans

Changes

Fix EvalPlanQual rechecks involving CTE scans (Tom Lane)

The recheck would always see the CTE as returning no rows, typically leading to failure to update rows that were recently updated.

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 improper repetition of previous results from hashed aggregation in a subquery

Changes

Fix improper repetition of previous results from hashed aggregation in a subquery (Andrew Gierth)

The test to see if we can reuse a previously-computed hash table of the aggregate state values neglected the possibility of an outer query reference appearing in an aggregate argument expression. A change in the value of such a reference should lead to recalculating the hash table, but did not.

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 query-lifespan memory leak in a bulk UPDATE on a table with a PRIMARY KEY or REPLICA IDENTITY index

Changes

Fix query-lifespan memory leak in a bulk UPDATE on a table with a PRIMARY KEY or REPLICA IDENTITY index (Tom Lane)

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.

Bug fixesFix EXPLAIN to emit valid XML when track_io_timing is on

Changes

Fix EXPLAIN to emit valid XML when track_io_timing is on (Markus Winand)

Previously the XML output-format option produced syntactically invalid tags such as <I/O-Read-Time>. That is now rendered as <I-O-Read-Time>.

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.

ImprovementsSuppress printing of zeroes for unmeasured times in EXPLAIN

Changes

Suppress printing of zeroes for unmeasured times in EXPLAIN (Maksim Milyutin)

Certain option combinations resulted in printing zero values for times that actually aren't ever measured in that combination. Our general policy in EXPLAIN is not to print such fields at all, so do that consistently in all cases.

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.

Bug fixesFix timeout length when VACUUM is waiting for exclusive table lock so that it can truncate the table

Changes

Fix timeout length when VACUUM is waiting for exclusive table lock so that it can truncate the table (Simon Riggs)

The timeout was meant to be 50 milliseconds, but it was actually only 50 microseconds, causing VACUUM to give up on truncation much more easily than intended. Set it to the intended value.

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 bugs in merging inherited CHECK constraints while creating or altering a table

Changes

Fix bugs in merging inherited CHECK constraints while creating or altering a table (Tom Lane, Amit Langote)

Allow identical CHECK constraints to be added to a parent and child table in either order. Prevent merging of a valid constraint from the parent table with a NOT VALID constraint on the child. Likewise, prevent merging of a NO INHERIT child constraint with an inherited constraint.

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 artificial restrictions on the values accepted by numeric_in() and numeric_recv()

Changes

Remove artificial restrictions on the values accepted by numeric_in() and numeric_recv() (Tom Lane)

We allow numeric values up to the limit of the storage format (more than 1e100000), so it seems fairly pointless that numeric_in() rejected scientific-notation exponents above 1000. Likewise, it was silly for numeric_recv() to reject more than 1000 digits in an input value.

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 fixesAvoid very-low-probability data corruption due to testing tuple visibility without holding buffer lock

Changes

Avoid very-low-probability data corruption due to testing tuple visibility without holding buffer lock (Thomas Munro, Peter Geoghegan, Tom Lane)

Related records (5)

“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 logical WAL decoding to work properly when a subtransaction's WAL output is large enough to spill to disk

Changes

Fix logical WAL decoding to work properly when a subtransaction's WAL output is large enough to spill to disk (Andres Freund)

Related records (2)

“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 buffer overread in logical WAL decoding

Changes

Fix buffer overread in logical WAL decoding (Tom Lane)

Logical decoding of a tuple update record read 23 bytes too many, which was usually harmless but with very bad luck could result in a crash.

Bug fixesFix file descriptor leakage when truncating a temporary relation of more than 1GB

Changes

Fix file descriptor leakage when truncating a temporary relation of more than 1GB (Andres Freund)

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.

ImprovementsDisallow starting a standalone backend with standby_mode turned on

Changes

Disallow starting a standalone backend with standby_mode turned on (Michael Paquier)

This can't do anything useful, since there will be no WAL receiver process to fetch more WAL data; and it could result in misbehavior in code that wasn't designed with this situation in mind.

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.

ImprovementsProperly initialize replication slot state when recycling a previously-used slot

Changes

Properly initialize replication slot state when recycling a previously-used slot (Michael Paquier)

This failure to reset all of the fields of the slot could prevent VACUUM from removing dead tuples.

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.

ImprovementsRound shared-memory allocation request to a multiple of the actual huge page size when attempting to use huge pages on Linux

Changes

Round shared-memory allocation request to a multiple of the actual huge page size when attempting to use huge pages on Linux (Tom Lane)

This avoids possible failures during munmap() on systems with atypical default huge page sizes. Except in crash-recovery cases, there were no ill effects other than a log message.

Related records (2)

“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.

ImprovementsUse a more random value for the dynamic shared memory control segment's ID

Changes

Use a more random value for the dynamic shared memory control segment's ID (Robert Haas, Tom Lane)

Previously, the same value would be chosen every time, because it was derived from random() but srandom() had not yet been called. While relatively harmless, this was not the intended behavior.

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.

ImprovementsOn Windows, retry creation of the dynamic shared memory control segment after an access-denied error

Changes

On Windows, retry creation of the dynamic shared memory control segment after an access-denied error (Kyotaro Horiguchi, Amit Kapila)

Windows sometimes returns ERROR_ACCESS_DENIED rather than ERROR_ALREADY_EXISTS when there is an existing segment. This led to postmaster startup failure due to believing that the former was an unrecoverable error.

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.

ImprovementsDon't try to share SSL contexts across multiple connections in libpq

Changes

Don't try to share SSL contexts across multiple connections in libpq (Heikki Linnakangas)

This led to assorted corner-case bugs, particularly when trying to use different SSL parameters for different connections.

Related records (5)

“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 fixesAvoid corner-case memory leak in libpq

Changes

Avoid corner-case memory leak in libpq (Tom Lane)

The reported problem involved leaking an error report during PQreset(), but there might be related cases.

Related records (5)

“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.

ImprovementsMake ecpg's --help and --version options work consistently with our other executables

Changes

Make ecpg's --help and --version options work consistently with our other executables (Haribabu Kommi)

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 pgbench's calculation of average latency

Changes

Fix pgbench's calculation of average latency (Fabien Coelho)

The calculation was incorrect when there were \sleep commands in the script, or when the test duration was specified in number of transactions rather than total time.

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.

ImprovementsIn pg_dump, never dump range constructor functions

Changes

In pg_dump, never dump range constructor functions (Tom Lane)

This oversight led to pg_upgrade failures with extensions containing range types, due to duplicate creation of the constructor functions.

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.

ImprovementsIn pg_xlogdump, retry opening new WAL segments when using --follow option

Changes

In pg_xlogdump, retry opening new WAL segments when using --follow option (Magnus Hagander)

This allows for a possible delay in the server's creation of the next segment.

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.

Bug fixesFix pg_xlogdump to cope with a WAL file that begins with a continuation record spanning more than one page

Changes

Fix pg_xlogdump to cope with a WAL file that begins with a continuation record spanning more than one page (Pavan Deolasee)

Related records (2)

“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 contrib/pg_buffercache to work when shared_buffers exceeds 256GB

Changes

Fix contrib/pg_buffercache to work when shared_buffers exceeds 256GB (KaiGai Kohei)

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.

Bug fixesFix contrib/intarray/bench/bench.pl to print the results of the EXPLAIN it does when given the -e option

Changes

Fix contrib/intarray/bench/bench.pl to print the results of the EXPLAIN it does when given the -e option (Daniel Gustafsson)

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.

ImprovementsInstall TAP test infrastructure so that it's available for extension testing

Changes

Install TAP test infrastructure so that it's available for extension testing (Craig Ringer)

When PostgreSQL has been configured with --enable-tap-tests, "make install" will now install the Perl support files for TAP testing where PGXS can find them. This allows non-core extensions to use $(prove_check) without extra tests.

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.

ImprovementsIn MSVC builds, include pg_recvlogical in a client-only installation

Changes

In MSVC builds, include pg_recvlogical in a client-only installation (MauMau)

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.

ImprovementsUpdate Windows time zone mapping to recognize some time zone names added in recent Windows versions

Changes

Update Windows time zone mapping to recognize some time zone names added in recent Windows versions (Michael Paquier)

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.

ImprovementsPrevent failure of obsolete dynamic time zone abbreviations

Changes

Prevent failure of obsolete dynamic time zone abbreviations (Tom Lane)

If a dynamic time zone abbreviation does not match any entry in the referenced time zone, treat it as equivalent to the time zone name. This avoids unexpected failures when IANA removes abbreviations from their time zone database, as they did in tzdata release 2016f and seem likely to do again in the future. The consequences were not limited to not recognizing the individual abbreviation; any mismatch caused the pg_timezone_abbrevs view to fail altogether.

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.

ImprovementsUpdate time zone data files to tzdata release 2016h for DST law changes in Palestine and Turkey, plus historical corrections for Turkey and some regions of Russia. Switch to numeric abbreviations for some time zones in Antarctica, the former Soviet Union, and Sri Lanka.

Changes

Update time zone data files to tzdata release 2016h for DST law changes in Palestine and Turkey, plus historical corrections for Turkey and some regions of Russia. Switch to numeric abbreviations for some time zones in Antarctica, the former Soviet Union, and Sri Lanka.

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.

In this update, AMT is no longer shown as being in use to mean Armenia Time. Therefore, we have changed the Default abbreviation set to interpret it as Amazon Time, thus UTC-4 not UTC+4.

Related records (5)

“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.