Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?
Date
Msg-id CAH2-WzkPEAhuB=ggPywrkfj9K5muhZbuxsj775=aNqhx1yi93A@mail.gmail.com
Whole thread Raw
In response to Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Dec 17, 2024 at 10:51 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I think this amounts to inventing a new way to mark a tuple as dead,
> but I don't think we need to do that. We could just mark the line
> pointer LP_DEAD without actually touching the space that contains the
> tuple. At least, I think that would work.

You might well be right about that. HOT chains might make things more
complicated (a heap-only tuple can only be set LP_UNUSED), but we
could probably figure that out if we had to.

I'm not entirely sure that this would be worth the effort. I believe
that having to wait for a cleanup lock is rare in general. On the
other hand, it'd be convenient if the high-level design of
VACUUM/autovacuum scheduling could freely ignore the possibility of
having to wait for a cleanup lock.

> The only question in my mind
> is whether whatever we propose to do here would violate the locking
> rules documented in src/backend/storage/buffer/README. In my opinion,
> those rules are a bit vaguely worded in some places, but I interpret
> #1 and #2 as meaning that you can't look at the line pointer array
> without some kind of content lock, so an exclusive content lock should
> be good enough to mark a line pointer dead as long as you don't
> relocate any tuples.

That is also my interpretation.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?
Next
From: Andres Freund
Date:
Subject: Re: Adding NetBSD and OpenBSD to Postgres CI