Re: pg_upgradecluster and synchronous replication

From: Christoph Berg <myon(at)debian(dot)org>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: pgsql-pkg-debian(at)lists(dot)postgresql(dot)org
Subject: Re: pg_upgradecluster and synchronous replication
Date: 2026-01-14 19:39:35
Message-ID: aWfw90dIjJEui1QF@msg.df7cb.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-pkg-debian

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

In response to

Responses

Browse pgsql-pkg-debian by date

  From Date Subject
Next Message Laurenz Albe 2026-01-14 19:54:43 Re: pg_upgradecluster and synchronous replication
Previous Message Laurenz Albe 2026-01-14 17:50:00 pg_upgradecluster and synchronous replication