MIME-Version: 1.0
References: <CAH2-Wz=iLnf+0CsaB37efXCGMRJO1DyJw5HMzm7tp1AxG1NR2g@mail.gmail.com>
 <CAH2-WzkUBbg9SSL7bFWT_Y86027GAUJEgqwgbe2YjOLEpw9ysQ@mail.gmail.com>
 <CAH2-Wzk=uUHMPx3Zs41ouPBgxX-5BbwSuPeOBLyKt3y5jt-sgw@mail.gmail.com>
 <CA+TgmoZMKKO_dGBhEzZ5T8jbmL+3kxSuLoQx_pyDfHKutiifCg@mail.gmail.com>
 <CAH2-WzmfyfmmANV6RRchHmUBgjU9QYBUP_6CoFuQ3d23T4E6nQ@mail.gmail.com>
 <20220218221117.ijozsjwaxa6fy5u6@alap3.anarazel.de> <CAH2-Wz=DHb2hXGqcvuVyy0qC88VcYoaNjy2FFtb-xjQMOZTQqw@mail.gmail.com>
 <CAH2-WzkiB-qcsBmWrpzP0nxvrQExoUts1d7TYShg_DrkOHeg4Q@mail.gmail.com>
 <CAH2-WzkPb42odWen-HZRYw1zUe=fPAp1_JbSuVvPXQTO2iBMPw@mail.gmail.com>
 <CAH2-WzmXiYMPX80AJnUoOdQZ3VRGyzan+xvdg1ayG8w1Ld2riw@mail.gmail.com> <20220220015416.gxnocs4we56ghmj3@alap3.anarazel.de>
In-Reply-To: <20220220015416.gxnocs4we56ghmj3@alap3.anarazel.de>
From: Robert Haas <robertmhaas@gmail.com>
Date: Sun, 20 Feb 2022 10:03:17 -0500
Message-ID: <CA+TgmoaND-vz-jJh8F6Sh4izW-t6ECVxB9JAw7mpQr9L-YJ9YA@mail.gmail.com>
Subject: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
To: Andres Freund <andres@anarazel.de>
Cc: Peter Geoghegan <pg@bowt.ie>, Masahiko Sawada <sawada.mshk@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoaND-vz-jJh8F6Sh4izW-t6ECVxB9JAw7mpQr9L-YJ9YA%40mail.gmail.com>
Precedence: bulk

On Sat, Feb 19, 2022 at 8:54 PM Andres Freund <andres@anarazel.de> wrote:
> > Leaving behind disconnected/orphaned heap-only tuples is pretty much
> > pointless anyway, since they'll never be accessible by index scans.
> > Even after a REINDEX, since there is no root item from the heap page
> > to go in the index. (A dump and restore might work better, though.)
>
> Given that heap_surgery's raison d'etre is correcting corruption etc, I think
> it makes sense for it to do as minimal work as possible. Iterating through a
> HOT chain would be a problem if you e.g. tried to repair a page with HOT
> corruption.

Yeah, I agree. I don't have time to respond to all of these emails
thoroughly right now, but I think it's really important that
pg_surgery do the exact surgery the user requested, and not any other
work. I don't think that page defragmentation should EVER be REQUIRED
as a condition of other work. If other code is relying on that, I'd
say it's busted. I'm a little more uncertain about the case where we
kill the root tuple of a HOT chain, because I can see that this might
leave the page a state where sequential scans see the tuple at the end
of the chain and index scans don't. I'm not sure whether that should
be the responsibility of pg_surgery itself to avoid, or whether that's
your problem as a user of it -- although I lean mildly toward the
latter view, at the moment. But in any case surely the pruning code
can't just decide to go into an infinite loop if that happens. Code
that manipulates the states of data pages needs to be as robust
against arbitrary on-disk states as we can reasonably make it, because
pages get garbled on disk all the time.

-- 
Robert Haas
EDB: http://www.enterprisedb.com