Re: pgsql: Trial fix for old cross-version upgrades. - Mailing list pgsql-committers

From Jeff Davis
Subject Re: pgsql: Trial fix for old cross-version upgrades.
Date
Msg-id 7fe52cfdc373df817e303050f1f10f25dcdf4390.camel@j-davis.com
Whole thread Raw
In response to Re: pgsql: Trial fix for old cross-version upgrades.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Trial fix for old cross-version upgrades.
List pgsql-committers
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.
>
> 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.

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=copperhead&dt=2025-02-22%2009%3A10%3A36&stg=xversion-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




pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Trial fix for old cross-version upgrades.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Trial fix for old cross-version upgrades.