Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?
От | Robert Haas |
---|---|
Тема | Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit? |
Дата | |
Msg-id | CA+TgmobdMrDv3PHeJK_EeacRn6LGg9d+YNQOqEV+-zE2knDkJQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit? (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?
|
Список | 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 по дате отправления: