On Mon, Dec 16, 2024 at 2:17 PM Peter Geoghegan <p...@bowt.ie> wrote: > Maybe it's a good idea, but right now it poses a similar risk to my > scenario involving a random, isolated SELECT FOR SHARE that happens to > affect some random tuple on a cold/frozen page. Of course, this > wouldn't be all that hard to fix.
BTW, one alternative to a "retry cleanup lock acquisition 3 times" heuristic is a version of freezing/pruning that doesn't require a cleanup lock at all. 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 don't think that problems with acquiring cleanup locks happen all that often -- they're probably very rare. But when they do happen they can be extremely serious -- they can even cause outages. And so there's a lot to be said for a design that removes those sorts of risks (or that at least significantly ameliorates them). It gives you the freedom to come up with better high-level designs that don't have to worry about not acquiring cleanup locks. -- Peter Geoghegan
