Date: Wed, 14 Jan 2026 20:39:35 +0100
From: Christoph Berg <myon@debian.org>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: pgsql-pkg-debian@lists.postgresql.org
Subject: Re: pg_upgradecluster and synchronous replication
Message-ID: <aWfw90dIjJEui1QF@msg.df7cb.de>
References: <d3f21029c8ea11f6a61cfb8045ac11480787411e.camel@cybertec.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d3f21029c8ea11f6a61cfb8045ac11480787411e.camel@cybertec.at>
Archived-At: 
 <https://www.postgresql.org/message-id/aWfw90dIjJEui1QF%40msg.df7cb.de>
Precedence: bulk

Re: Laurenz Albe
>   vacuumdb ... --analyze-in-stages --missing-stats-only
> 
> processing hung, because the synchronous standby was not available and the transaction
> could not commit.

Interesting find, thanks for sharing.

> Yet I wonder if pg_upgradecluster could improve things by disabling synchronous_standby_names
> when the cluster ist started for the "finish" stage.  I have attached a POC patch how this
> could be done.  I didn't test it, and my Perl skills are marginal, but you get the idea.

That's also the command that does the final cluster start for
production, I wouldn't want such a change to persist.

Maybe we should instead change the analyze hook script to do that
internally? Setting PGOPTIONS should be enough:

    PGOPTIONS="-csynchronous_commit=local"

> Perhaps this is too much black magic, not sure.  But I wanted to share my experience.

There is already some code in pg_upgradecluster that works around
black magic problems:

    # ensure we can upgrade DBs with default read-only transactions
    $ENV{PGOPTIONS} .= " -cdefault_transaction_read_only=off";

This would just add one more wart of that kind.

Christoph