Re: pg_upgradecluster and synchronous replication - Mailing list pgsql-pkg-debian

From Christoph Berg
Subject Re: pg_upgradecluster and synchronous replication
Date
Msg-id aWfw90dIjJEui1QF@msg.df7cb.de
Whole thread Raw
In response to pg_upgradecluster and synchronous replication  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: pg_upgradecluster and synchronous replication
List 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



pgsql-pkg-debian by date:

Previous
From: Laurenz Albe
Date:
Subject: pg_upgradecluster and synchronous replication
Next
From: Laurenz Albe
Date:
Subject: Re: pg_upgradecluster and synchronous replication