Skip to content
dbexplore

Question: Upgrades

Does a minor version upgrade need pg_upgrade?

Answered in the first paragraph. Last updated .

No. The documentation says the tool is not required for minor upgrades, and it is not required because nothing in the data directory changes. Install the new package, restart the server, and you are finished. The downtime is one restart. Minor releases are where security fixes and data-loss bug fixes ship, so the thing that carries real risk is not applying one but deferring several.

The part of a minor upgrade that is not automatic

Occasionally a minor release fixes a bug whose effects are already on disk, and repairing those effects needs a manual step after the restart, typically rebuilding indexes of a particular kind. Nothing prompts you. The release notes say so and are the only place it is written, which is the practical reason to read them for every release you skip over rather than only for the one you land on.

Extensions with a compiled component have to match the server build, so a package upgrade that replaces the server without replacing them leaves functions that will not load. pg_upgrade and extensions covers taking that inventory, and it applies to minor upgrades more often than people expect.

On a replicated pair, the usual order is standbys first and the primary last, so that at no point is a standby running older code than the primary it is replaying from.

Why deferring them is the expensive choice

Fixes only ship forward. A cluster three minor releases behind is carrying every bug fixed in those three, including any that silently produce wrong results, and there is no supported way to get one fix without the others.

At the end of the line the releases stop altogether. A major version past its final release gets nothing, not even a security fix, which turns a routine restart into a major upgrade project under time pressure. The PostgreSQL 14 end-of-life audit is what that looks like when planned rather than discovered.

Two smaller points. A restart is a restart, so the same considerations apply as for any setting that requires one, covered in which settings need a restart. And a restart is not a risk to committed data, because the write-ahead log is what makes a clean shutdown and a crash converge on the same state anyway.

Put every Postgres you run on autopilot.

We onboard teams in small batches. Tell us about your fleet and we will reach out when a seat opens. One email, no drip campaign.