pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jonathan S. Katz <jkatz@postgresql.org>
Cc: Noah Misch <noah@leadboat.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Shruthi Gowda <gowdashru@gmail.com>
Subject: Re: pg15b2: large objects lost on upgrade
Date: Tue, 02 Aug 2022 15:32:05 -0400
Message-ID: <2684751.1659468725@sss.pgh.pa.us> (raw)
In-Reply-To: <d0a4f263-a774-394d-134f-4edce6a980e4@postgresql.org>
References: <YuCQQtF2p3qWs7t+@momjian.us>
	<CA+Tgmob6_NTj-euMShhcnAB_=CnkRO7-UgXVfWs4fACuDk8uAA@mail.gmail.com>
	<3901843.1659116952@sss.pgh.pa.us>
	<CA+TgmobzCRWG=_Tf0VXvF26pZbTxV-CKPNx6RdoWonKPETLvyQ@mail.gmail.com>
	<CA+TgmoYKVbB9rt2UAvaFLG-qYCgRuhAr7wPLDwTT0VpbPKvj_w@mail.gmail.com>
	<CA+TgmoZiBP2OD9POF0R2L=fib4ueOUusSVzmnO0_+kNzqSpnKw@mail.gmail.com>
	<4152163.1659124804@sss.pgh.pa.us>
	<CA+TgmoY=MfT2uc=N!4sAcHf3_teqYBNtmqVrVYv5oEK=4RfxATw@mail.gmail.com>
	<CA+TgmoZX6Zz4KU2enOYyc+aQWA+S5ZaZRGo6BgxW7mNF4btqaw@mail.gmail.com>
	<125444.1659136594@sss.pgh.pa.us>
	<20220730054401.GB3644221@rfd.leadboat.com>
	<351616.1659192034@sss.pgh.pa.us>
	<635c8809-3525-7dae-a1a1-0d9069cd86bc@postgresql.org>
	<2657259.1659460333@sss.pgh.pa.us>
	<d0a4f263-a774-394d-134f-4edce6a980e4@postgresql.org>

"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 8/2/22 1:12 PM, Tom Lane wrote:
>> Sadly, we're still not out of the woods.  I see three buildfarm
>> failures in this test since Robert resolved the "-X" problem [1][2][3]:

> Looking at the test code, is there anything that could have changed the 
> relfrozenxid or relminxid independently of the test on these systems?

Hmmm ... now that you mention it, I see nothing in 002_pg_upgrade.pl
that attempts to turn off autovacuum on either the source server or
the destination.  So one plausible theory is that autovac moved the
numbers since we checked.

If that is the explanation, then it leaves us with few good options.
I am not in favor of disabling autovacuum in the test: ordinary
users are not going to do that while pg_upgrade'ing, so it'd make
the test less representative of real-world usage, which seems like
a bad idea.  We could either drop this particular check again, or
weaken it to allow new relfrozenxid >= old relfrozenxid, likewise
relminxid.

			regards, tom lane





view thread (97+ messages)  latest in thread

Message-ID: <2684751.1659468725@sss.pgh.pa.us>
Permalink:  ../2684751.1659468725@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2684751.1659468725@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, jkatz@postgresql.org, noah@leadboat.com, robertmhaas@gmail.com, andrew@dunslane.net, bruce@momjian.us, michael@paquier.xyz, pryzby@telsasoft.com, gowdashru@gmail.com
  Subject: Re: pg15b2: large objects lost on upgrade
  In-Reply-To: <2684751.1659468725@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox