Subject: Major upgrade in patroni cluster

From: Raj <[email-masked]>
Date: Sun, 28 Jun 2026 21:53:00 +0530

Hi All,

I have a three node PATRONI cluster with postgres 17.10 version with
PGBACKREST, pgnouncer and haproxy.

We would like to upgrade postgres 18.4 version.

What are the high level steps with minimal downtime? Though I did some
research already, would like to understand how it's been followed.

---

From: Mahesh Sathe <[email-masked]>
Date: Mon, 6 Jul 2026 16:06:13 +0530

Hi Raj,

For a 3-node Patroni cluster with PostgreSQL 17.10, here is the high-level
approach I typically follow for a major version upgrade to 18.4 with
minimal downtime.High-Level Strategy

   1. *Preparation & Testing*:
      - *Staging Environment*: Perform the upgrade on a staging cluster
      that mirrors your production setup. This is critical for validating
      application compatibility and performance.
      - *Release Notes*: Thoroughly review the release notes for PostgreSQL
      18.4 to identify any breaking changes, deprecated features, or specific
      collation/locale requirements that might impact your data.
      - *Testing*: Validate your pgBackRest backups and ensure you can
      restore from them before proceeding.
   2. *Upgrade Execution (Minimal Downtime)*:
      - *Rolling Upgrade*: Utilize Patroni’s rolling upgrade capability.
      You can upgrade one replica at a time by stopping the Patroni service,
      upgrading the PostgreSQL binaries, and restarting.
      - *Switchover*: Once the replicas are upgraded, perform a controlled
      switchover to promote an upgraded replica to leader. Finally, upgrade the
      former leader.
      - *pg_upgrade*: In many cases, you may need to use the
pg_upgrade utility.
      If you use it, ensure you run it with the -k (link) option where
      possible to significantly speed up the process and minimize downtime.
   3. *Key Considerations*:
      - *OS/Library Compatibility*: Since you are moving to a newer PG
      version, ensure the underlying OS libraries (especially glibc) are
      compatible, as this can affect collation.
      - *PgBouncer/HAProxy*: Ensure your connection poolers and HA setup
      are correctly updated to point to the new binary paths if the
installation
      location changes.
      - *Validation*: After the upgrade, run your application suite against
      the cluster to catch any performance regressions.

Let me know if you’d like to discuss specific steps for the pg_upgrade process
or how to handle the replication configuration changes.

Best regards,

Mahesh Sathe

Sent from Gmail Mobile

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 6 Jul 2026 10:43:52 +0000

Hi Mahesh!

Do I understand it right, that during the rolling upgrade you loose High Availability as for short time the Patroni nodes use a different Postgres version and hence the streaming replication will not work?

regards
Klaus

________________________________
Von: Mahesh Sathe <[email-masked]>
Gesendet: Montag, 6. Juli 2026 12:36
An: Raj <[email-masked]>
Cc: Pgsql-admin <[email-masked]>
Betreff: Re: Major upgrade in patroni cluster

Hi Raj,

For a 3-node Patroni cluster with PostgreSQL 17.10, here is the high-level approach I typically follow for a major version upgrade to 18.4 with minimal downtime.High-Level Strategy

  1.  Preparation & Testing:
     *   Staging Environment: Perform the upgrade on a staging cluster that mirrors your production setup. This is critical for validating application compatibility and performance.
     *   Release Notes: Thoroughly review the release notes for PostgreSQL 18.4 to identify any breaking changes, deprecated features, or specific collation/locale requirements that might impact your data.
     *   Testing: Validate your pgBackRest backups and ensure you can restore from them before proceeding.
  2.  Upgrade Execution (Minimal Downtime):
     *   Rolling Upgrade: Utilize Patroni’s rolling upgrade capability. You can upgrade one replica at a time by stopping the Patroni service, upgrading the PostgreSQL binaries, and restarting.
     *   Switchover: Once the replicas are upgraded, perform a controlled switchover to promote an upgraded replica to leader. Finally, upgrade the former leader.
     *   pg_upgrade: In many cases, you may need to use the pg_upgrade utility. If you use it, ensure you run it with the -k (link) option where possible to significantly speed up the process and minimize downtime.
  3.  Key Considerations:
     *   OS/Library Compatibility: Since you are moving to a newer PG version, ensure the underlying OS libraries (especially glibc) are compatible, as this can affect collation.
     *   PgBouncer/HAProxy: Ensure your connection poolers and HA setup are correctly updated to point to the new binary paths if the installation location changes.
     *   Validation: After the upgrade, run your application suite against the cluster to catch any performance regressions.

Let me know if you’d like to discuss specific steps for the pg_upgrade process or how to handle the replication configuration changes.

Best regards,

Mahesh Sathe

Sent from Gmail Mobile

On Sun, 28 Jun 2026 at 9:53 PM, Raj <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

I have a three node PATRONI cluster with postgres 17.10 version with PGBACKREST, pgnouncer and haproxy.

What are the high level steps with minimal downtime? Though I did some research already, would like to understand how it's been followed.

---

From: Michael Banck <[email-masked]>
Date: Mon, 6 Jul 2026 12:52:10 +0200

On Mon, Jul 06, 2026 at 10:43:52AM +0000, Klaus Darilion wrote:
> Do I understand it right, that during the rolling upgrade you loose
> High Availability as for short time the Patroni nodes use a different
> Postgres version and hence the streaming replication will not work?

That is correct, and short of using logical replication for
zero-downtime upgrade into a separate, new, Patroni cluster, I don't see
how to circumvent this.

One can make the upgrade window smaller by upgrading the standbys with
rsync, but that is quite brittle and should only be done in controlled
environments after lots of testing. Also, it only works with the --link
pg_upgrade option, not --copy or --clone.

Michael

---

From: Michael Banck <[email-masked]>
Date: Mon, 6 Jul 2026 12:56:19 +0200

Hi,

On Mon, Jul 06, 2026 at 04:06:13PM +0530, Mahesh Sathe wrote:
> For a 3-node Patroni cluster with PostgreSQL 17.10, here is the
> high-level approach I typically follow for a major version upgrade to
> 18.4 with minimal downtime.

> High-Level Strategy

I think you issued the wrong prompt here, because the AI answer
describes a rolling minor-version upgrade.

You cannot run a major-version upgrade on a standby.

The proper high-level procedure is to run pg_upgrade on the leader and
to re-build the standbys afterwards, either through re-clone or via
rsync (see my other message).

In terms of Patroni, one also needs to make sure the DCS configuration
is updated, usually by removing it from DCS and letting Patroni recreate
it.

In general, the procedure is quite well described in the Patroni
documentation here:

https://patroni.readthedocs.io/en/latest/existing_data.html#major-upgrade-of-postgresql-version

Michael