public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jeff Davis <[email protected]>
To: Tom Lane <[email protected]>
To: Andrew Dunstan <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: [email protected]
Subject: Re: pgsql: Trial fix for old cross-version upgrades.
Date: Sat, 22 Feb 2025 17:25:43 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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...

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

view thread (30+ messages)  latest in thread

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pgsql: Trial fix for old cross-version upgrades.
  In-Reply-To: <[email protected]>

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

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