From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Avoiding unnecessary clog lookups while freezing |
Date: | 2022-12-29 06:36:53 |
Message-ID: | CAH2-Wznyx4x4OoJVeztmMh3iiSEU=xQXmP593Q8qKUR-289-qA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 28, 2022 at 4:43 PM Andres Freund <andres(at)anarazel(dot)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.
The important call to avoid with page-level freezing is the xmin call to
TransactionIdDidCommit(), not the xmax call. The xmax call only occurs
when VACUUM prepares to freeze a tuple that was updated by an updater
(not a locker) that aborted. While the xmin calls will now take place with most
unfrozen tuples.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Nikita Malakhov | 2022-12-29 07:39:34 | Re: split TOAST support out of postgres.h |
Previous Message | Peifeng Qiu | 2022-12-29 03:18:33 | psql: stop at error immediately during \copy |