Release notes are operational documentation for evaluating a PostgreSQL upgrade. They identify fixes, changed behavior, performance changes, security implications, and follow-up work that can alter the safety of an otherwise routine deployment. Read them before every upgrade, including minor releases, rather than treating them as historical detail. section 7.6 section 10.6
The tempting mistake is to read only the target major version’s notes when skipping versions. PostgreSQL permits direct major-version upgrades, but that convenience does not remove the need to inspect every intervening release: a relevant change may have been introduced well before the target version. Longer delays also make maintenance and the eventual upgrade path harder. section 7.6 section 10.1
Use release notes as an upgrade checklist:
- Read every intervening major release note from the running version through the target version; also read notes for each minor upgrade. section 7.6 section 10.1
- Look for behavior and performance changes that can affect application results, not only explicitly labeled breaking changes. section 10.1 section 10.6
- Identify remediation attached to fixes. An index-corruption fix in PostgreSQL 14.4 required REINDEX in some cases, and a security fix could affect pg_trgm users. section 7.6
- Check extension release schedules and compatibility with the PostgreSQL version being installed. section 7.6
- Test applications and queries against realistic data and workloads in staging before production rollout. section 10.6
A fractional interval changes after an upgrade
An application adds '0.333 years' to a subscription expiry. PostgreSQL 13 truncates the resulting 15.996 months to 15 months, producing 2025-04-01 from a 2025-01-01 expiry. PostgreSQL 16 produces 16 months and 2025-05-01 because PostgreSQL 15 changed fractional input above months to rounding. Reading only PostgreSQL 16 notes misses the origin of the change; reading notes for 13→14, 14→15, and 15→16 exposes it before diagnosis becomes a production incident. section 10.1
When interval input provides a fractional value for a unit greater than months, round to the nearest month (Bruce Momjian)
This release-note entry pinpoints the semantic change behind the interval result, turning an unexpected expiry date into a testable compatibility concern. section 10.1
Release-note review complements, rather than replaces, upgrade tooling. pg_upgrade has dry-run modes for sanity checks; logical replication can reduce downtime but needs more work. Neither tool discovers whether application assumptions about SQL behavior, extensions, or maintenance actions remain valid. Test those assumptions before deployment. section 7.6 section 10.6
