public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Andrew Dunstan <[email protected]>
Cc: Jeff Davis <[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 20:15:02 -0500
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]>

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

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