Re: Avoiding unnecessary clog lookups while freezing

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-12-29T00:43:15Z
Lists: pgsql-hackers
On 2022-12-28 16:37:27 -0800, Peter Geoghegan wrote:
> On Wed, Dec 28, 2022 at 4:20 PM Andres Freund <andres@anarazel.de> wrote:
> > > Theoretically this is an old issue that dates back to commit
> > > 699bf7d05c, as opposed to an issue in the page-level freezing patch.
> > > But that's not really true in a real practical sense. In practice the
> > > calls to TransactionIdDidCommit() will happen far more frequently
> > > following today's commit 1de58df4fe (since we're using OldestXmin as
> > > the cutoff that gates performing freeze_xmin/freeze_xmax processing --
> > > not FreezeLimit).
> >
> > Hm. But we still only do the check when we actually freeze, rather than just
> > during the pre-check in heap_tuple_should_freeze(). So we'll only incur the
> > increased overhead when we also do more WAL logging etc. Correct?
> 
> Yes, that's how it worked up until today's commit 1de58df4fe.
> 
> I don't have strong feelings about back patching a fix, but this does
> seem like something that I should fix now, on HEAD.
>
> > Hm. I dimply recall that we had repeated cases where the hint bits were set
> > wrongly due to some of the multixact related bugs. I think I was trying to be
> > paranoid about not freezing stuff in those situations, since it can lead to
> > reviving dead tuples, which obviously is bad.
> 
> I think that it's a reasonable check, and I'm totally in favor of
> keeping it (or something very close, at least).

I don't quite follow - one paragraph up you say we should fix something, and
then here you seem to say we should continue not to rely on the hint bits?



Commits

  1. Delay commit status checks until freezing executes.

  2. Add page-level freezing to VACUUM.

  3. Perform a lot more sanity checks when freezing tuples.