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

From Robert Haas
Subject Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?
Date
Msg-id CA+TgmobdMrDv3PHeJK_EeacRn6LGg9d+YNQOqEV+-zE2knDkJQ@mail.gmail.com
Whole thread Raw
In response to Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?
List pgsql-hackers
On Mon, Dec 16, 2024 at 2:38 PM Peter Geoghegan <pg@bowt.ie> wrote:
> The only reason that we require a cleanup lock is to make it safe to
> defragment the page, to free tuple space. Nothing stops you from
> inventing a variant of pruning/freezing that works just like regular
> pruning/freezing, but without attempting to free up tuple space --
> thus obviating the need for a cleanup lock. This process could still
> remove dead tuples by (say) setting their xmin to InvalidTransactionId
> -- that ought to still be safe.

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. 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.

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



pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Question about behavior of deletes with REPLICA IDENTITY NOTHING
Next
From: Andres Freund
Date:
Subject: Re: Crash: invalid DSA memory alloc request