You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful if pg_autoctl had a command to upgrade the primary and standby to a new version of Postgres via pg_upgrade without triggering a failover.
hope this feather will be able to use soon !
by now , is there any recommened steps to upgrade postgresql version in both primary / standby node ?
I try pg_upgradecluster , but that command create a new postgresql instance at different port , not managed by pg_auto_failover.
should I mark standy node to maintance , remove old version packages, install new packages , then come back to the cluster ?
or remove the standby node , create a new version instance , join to the cluster as standby , then switch standy node to primary , then upgrade the standby node (the original primary ) ?
Hi @changchichung ; I think we're going to explore how to best solve major upgrades with pg_upgradecluster at a later point in time. Another candidate for automating upgrades uses logical replication, which requires a third node at least during the upgrade. We don't have a recommended major upgrade process at this time.
This isn't solved end-to-end yet, but PR #1198 adds a building block that gets partway there: pg_autoctl restart postgres --exec "<command>".
It puts the node in maintenance, stops Postgres, runs an arbitrary operator-supplied command (any script or binary, via system() — same mechanism Postgres uses for archive_command) while Postgres is down, then starts it back up and leaves maintenance. That's enough to run something like pg_checksums --enable or a pg_upgrade step as the offline step, one node at a time, without the monitor triggering a failover.
What's still missing for a full solution to this issue is orchestration across both nodes (sequencing primary/standby, version coordination) — this just gives you the safe single-node primitive to build that on top of.
Not released yet — merged to main, should land in the next pg_auto_failover release, probably in November.
Activity
changchichung commentedon Oct 23, 2019
hope this feather will be able to use soon !
by now , is there any recommened steps to upgrade postgresql version in both primary / standby node ?
I try pg_upgradecluster , but that command create a new postgresql instance at different port , not managed by pg_auto_failover.
should I mark standy node to maintance , remove old version packages, install new packages , then come back to the cluster ?
or remove the standby node , create a new version instance , join to the cluster as standby , then switch standy node to primary , then upgrade the standby node (the original primary ) ?
DimCitus commentedon Oct 29, 2019
Hi @changchichung ; I think we're going to explore how to best solve major upgrades with
pg_upgradeclusterat a later point in time. Another candidate for automating upgrades uses logical replication, which requires a third node at least during the upgrade. We don't have a recommended major upgrade process at this time.s4ke commentedon Jun 1, 2020
Hey,
are there any updates on this? I would be happy to test this.
dimitri commentedon Oct 14, 2026
This isn't solved end-to-end yet, but PR #1198 adds a building block that gets partway there:
pg_autoctl restart postgres --exec "<command>".It puts the node in maintenance, stops Postgres, runs an arbitrary operator-supplied command (any script or binary, via
system()— same mechanism Postgres uses forarchive_command) while Postgres is down, then starts it back up and leaves maintenance. That's enough to run something likepg_checksums --enableor apg_upgradestep as the offline step, one node at a time, without the monitor triggering a failover.What's still missing for a full solution to this issue is orchestration across both nodes (sequencing primary/standby, version coordination) — this just gives you the safe single-node primitive to build that on top of.
Not released yet — merged to
main, should land in the next pg_auto_failover release, probably in November.