Message-ID: <5ebc188e731ac2b98d68459ce1a9ef3066981774.camel@j-davis.com>
Subject: Re: pgsql: Trial fix for old cross-version upgrades.
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <jdavis@postgresql.org>, Andrew Dunstan
 <andrew@dunslane.net>,  pgsql-committers@lists.postgresql.org
Date: Fri, 21 Feb 2025 18:48:40 -0800
In-Reply-To: <3815127.1740189601@sss.pgh.pa.us>
References: <E1tlBJt-000LUO-16@gemulon.postgresql.org>
	 <003dc9936317ab987faa0242f8e33e1cd2fcaf57.camel@j-davis.com>
	 <40c1e76334f2baa747334c8fc513d12b8cb297bf.camel@j-davis.com>
	 <3815127.1740189601@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/5ebc188e731ac2b98d68459ce1a9ef3066981774.camel%40j-davis.com>
Precedence: bulk

On Fri, 2025-02-21 at 21:00 -0500, Tom Lane wrote:
> I think we might indeed want that, but it doesn't seem to be the
> explanation for the buildfarm failures, because the diffs look
> to be consistent across runs which you'd not expect from
> autovacuum-driven changes.=C2=A0 I suspect that the problem is that
> pg_dump is interpreting old-version stats in some way that doesn't
> match up with what we get from restoring the dump.

I agree it doesn't explain the failures.

> I did experiment with the attached very-quick-n-dirty patch, which
> should succeed in suppressing autovacuum in both the old and new
> versions if I understand the code correctly (which I might well not).
> It made no difference at all in the dump diffs ...

In 002_pg_upgrade.pl, I disabled autovacuum and restarted after the
regression run. In other words, in the old cluster, autovacuum did have
a chance to run, just not after the first dumpall.

Regards,
	Jeff Davis