From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Jeff Davis <pgsql@j-davis.com>, Jeff Davis <jdavis@postgresql.org>,
        pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Trial fix for old cross-version upgrades.
In-reply-to: <301492.1740249291@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>
 <5ebc188e731ac2b98d68459ce1a9ef3066981774.camel@j-davis.com>
 <3892121.1740193866@sss.pgh.pa.us>
 <976dcc37-b629-490e-a052-a057477d062f@dunslane.net>
 <301492.1740249291@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 22 Feb 2025 13:34:51 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <684273.1740273302.1@sss.pgh.pa.us>
Date: Sat, 22 Feb 2025 20:15:02 -0500
Message-ID: <684274.1740273302@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/684274.1740273302%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> So there's our extra round of ANALYZE right there.  I diked out the
> vacuumdb call and things are working much better.  It seems to pass
> for branches back through 9.3, and upgrade from 9.2 has only some
> diffs for relallvisible (see attached).

I confess that when I wrote that, I hadn't actually tested every
single branch as an upgrade source.  After seeing the latest result
from crake (which failed at 9.6), I went back and filled in the gaps.
I can now say that 9.2 and 9.6 fail, but every other branch works.
What's more, the diffs from 9.2 and 9.6 are identical, and match
what crake is showing for 9.6.  That's just crazy --- I would be
unsurprised if a range of back releases were misbehaving in the same
way, but not two isolated branches.

Furthermore, it can't be a coincidence that the four tables we are
seeing relallvisible diffs for are exactly the four tables in the
regression database that have hash indexes.

But I'm baffled where to look beyond that.  I could believe that
CREATE INDEX with a hash index misbehaves by changing the
relallvisible value even when we're doing a binary upgrade --- but
such a bug would be on the restoring side, so how would it be
sensitive to the source branch?  I'm confused.

			regards, tom lane