Re: Avoiding unnecessary clog lookups while freezing - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Avoiding unnecessary clog lookups while freezing
Date
Msg-id 20221229172101.p24xojcaadsrrucl@awork3.anarazel.de
Whole thread Raw
In response to Re: Avoiding unnecessary clog lookups while freezing  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Avoiding unnecessary clog lookups while freezing
Re: Avoiding unnecessary clog lookups while freezing
List pgsql-hackers
Hi,

On 2022-12-28 22:36:53 -0800, Peter Geoghegan wrote:
> On Wed, Dec 28, 2022 at 4:43 PM Andres Freund <andres@anarazel.de> wrote:
> > > > 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?
> 
> I didn't mean that we should continue to not rely on the hint bits. Is
> that really all that the test is for? I think of it as a general sanity check.

I do think we wanted to avoid reviving actually-dead tuples (present due to
the multixact and related bugs). And I'm worried about giving that checking
up, I've seen it hit too many times. Both in the real world and during
development.

Somewhat of a tangent: I've previously wondered if we should have a small
hash-table based clog cache. The current one-element cache doesn't suffice in
a lot of scenarios, but it wouldn't take a huge cache to end up filtering most
clog accesses.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: split TOAST support out of postgres.h
Next
From: Tom Lane
Date:
Subject: Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)