Message-ID: <d3f21029c8ea11f6a61cfb8045ac11480787411e.camel@cybertec.at>
Subject: pg_upgradecluster and synchronous replication
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: pgsql-pkg-debian@lists.postgresql.org
Date: Wed, 14 Jan 2026 18:50:00 +0100
Content-Type: multipart/mixed; boundary="=-QuwIKJaG7VK1vfKCjlhC"
User-Agent: Evolution 3.58.2 (3.58.2-1.fc43) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/d3f21029c8ea11f6a61cfb8045ac11480787411e.camel%40cybertec.at>
Precedence: bulk

--=-QuwIKJaG7VK1vfKCjlhC
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I ran into a problem today during a training session when I demonstrated

  pg_upgradecluster -v 18 --method=3Dupgrade --link 17 main

The problem was that I had configured synchronous streaming replication fir=
st, so after
pg_upgrade, the synchronous standby was lost, and when pg_upgradecluster ra=
n

  vacuumdb ... --analyze-in-stages --missing-stats-only

processing hung, because the synchronous standby was not available and the =
transaction
could not commit.

Yes, that was my mistake, and yes, the problem was easily fixed by interrup=
ting
pg_upgradecluster, disabling synchronous_standby_names and running the ANAL=
YZE
and v17 cluster removal manually.

Yet I wonder if pg_upgradecluster could improve things by disabling synchro=
nous_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.

Perhaps this is too much black magic, not sure.  But I wanted to share my e=
xperience.

Yours,
Laurenz Albe

--=-QuwIKJaG7VK1vfKCjlhC
Content-Disposition: attachment; filename="pg_upgradecluster-analyze.patch"
Content-Type: text/x-patch; name="pg_upgradecluster-analyze.patch";
 charset="UTF-8"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3BnX3VwZ3JhZGVjbHVzdGVyIGIvcGdfdXBncmFkZWNsdXN0ZXIKaW5kZXgg
MDk5NzljMy4uMTY5OGJhOCAxMDA3NTUKLS0tIGEvcGdfdXBncmFkZWNsdXN0ZXIKKysrIGIvcGdf
dXBncmFkZWNsdXN0ZXIKQEAgLTc0Myw3ICs3NDMsNyBAQCBpZiAobm90IGV4aXN0cyAkRU5WeydQ
R19DTFVTVEVSX0NPTkZfUk9PVCd9IGFuZCAtZCAnL3J1bi9zeXN0ZW1kL3N5c3RlbScgYW5kICQ+
CiAkc3RhcnQgPSAoJGluZm97cnVubmluZ30gb3IgJHVwZ3JhZGVfc2NyaXB0cykgaWYgKCRzdGFy
dCA9PSAtMSk7CiBpZiAoJHN0YXJ0KSB7CiAgICAgcHJpbnQgIlN0YXJ0aW5nIHVwZ3JhZGVkIGNs
dXN0ZXIgb24gcG9ydCAkbmV3aW5mb3twb3J0fS4uLlxuIjsKLSAgICBAYXJndiA9ICgncGdfY3Rs
Y2x1c3RlcicsICRuZXd2ZXJzaW9uLCAkbmV3Y2x1c3RlciwgJ3N0YXJ0Jyk7CisgICAgQGFyZ3Yg
PSAoJ3BnX2N0bGNsdXN0ZXInLCAkbmV3dmVyc2lvbiwgJG5ld2NsdXN0ZXIsICdzdGFydCcsICct
LScsICctbycsICJcIi1jc3luY2hyb25vdXNfc3RhbmRieV9uYW1lcz0nJ1wiIik7CiAgICAgZXJy
b3IgIkNvdWxkIG5vdCBzdGFydCB1cGdyYWRlZCBjbHVzdGVyOyBwbGVhc2UgY2hlY2sgY29uZmln
dXJhdGlvbiBhbmQgbG9nIGZpbGVzIiBpZiBzeXN0ZW0gQGFyZ3Y7CiB9CiAK


--=-QuwIKJaG7VK1vfKCjlhC--