Message-ID: <7fe52cfdc373df817e303050f1f10f25dcdf4390.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>, Andrew Dunstan <andrew@dunslane.net>
Cc: Jeff Davis <jdavis@postgresql.org>, pgsql-committers@lists.postgresql.org
Date: Sat, 22 Feb 2025 17:25:43 -0800
In-Reply-To: <684274.1740273302@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> <684274.1740273302@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/7fe52cfdc373df817e303050f1f10f25dcdf4390.camel%40j-davis.com>
Precedence: bulk

On Sat, 2025-02-22 at 20:15 -0500, Tom Lane wrote:
> 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.
>=20
> 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.
>=20
> But I'm baffled where to look beyond that.=C2=A0 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?=C2=A0 I'm confused.

It's also strange that copperhead is consistently failing on 12 with:

  pg_restore: while PROCESSING TOC:
  pg_restore: from TOC entry 4163; 0 0 STATISTICS DATA "vcharidx" (no
owner)
  pg_restore: error: could not execute query: ERROR:  column "text" of
relation "vcharidx" does not exist

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=3Dcopperhead&=
dt=3D2025-02-22%2009%3A10%3A36&stg=3Dxversion-upgrade-REL_12_STABLE-HEAD

I was puzzling through whether the attribute name uniqueness logic was
doing something strange, but it's very simple. And the table and index
should both be locked at the point of the syscache lookup.

Regards,
	Jeff Davis