Re: visibility map corruption - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: visibility map corruption
Date
Msg-id CAH2-WznLucXZjchV9EN-p5H-V7y55a+FyXp1Z1vg3igTYfYgiw@mail.gmail.com
Whole thread Raw
In response to Re: visibility map corruption  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Tue, Jul 6, 2021 at 3:49 PM Bruce Momjian <bruce@momjian.us> wrote:
> My point is that there are a lot internals involved here that are not
> part of pg_upgrade, though it probably only affects pg_upgrade.  Anyway,
> Bertrand patch seems to have what I need.

I was confused by your remarks because I am kind of looking at it from
the opposite angle. At least now that I've thought about it a bit.

Since the snippet of pg_resetwal code that sets oldestXid wasn't ever
intended to be used by pg_upgrade, but was anyway, what we have is a
something that's clearly totally wrong (at least in the pg_upgrade
case). It's not just wrong for pg_upgrade to do things that way --
it's also wildly unreasonable. We heard a complaint about this from
Reddit only because it worked "as designed", and so made the cluster
immediately have an anti-wraparound autovacuum. But why would anybody
want that behavior, even if it was implemented correctly? It simply
makes no sense.

The consequences of this bug are indeed complicated and subtle and
will probably never be fully understood. But at the same time fixing
the bug now seems kind of simple. (Working backwards to arrive here
was a bit tricky, mind you.)

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: visibility map corruption
Next
From: Alvaro Herrera
Date:
Subject: Re: Column Filtering in Logical Replication