On Sat, Feb 19, 2022 at 8:54 PM Andres Freund <and...@anarazel.de> wrote: > > Leaving behind disconnected/orphaned heap-only tuples is pretty much > > pointless anyway, since they'll never be accessible by index scans. > > Even after a REINDEX, since there is no root item from the heap page > > to go in the index. (A dump and restore might work better, though.) > > Given that heap_surgery's raison d'etre is correcting corruption etc, I think > it makes sense for it to do as minimal work as possible. Iterating through a > HOT chain would be a problem if you e.g. tried to repair a page with HOT > corruption.
Yeah, I agree. I don't have time to respond to all of these emails thoroughly right now, but I think it's really important that pg_surgery do the exact surgery the user requested, and not any other work. I don't think that page defragmentation should EVER be REQUIRED as a condition of other work. If other code is relying on that, I'd say it's busted. I'm a little more uncertain about the case where we kill the root tuple of a HOT chain, because I can see that this might leave the page a state where sequential scans see the tuple at the end of the chain and index scans don't. I'm not sure whether that should be the responsibility of pg_surgery itself to avoid, or whether that's your problem as a user of it -- although I lean mildly toward the latter view, at the moment. But in any case surely the pruning code can't just decide to go into an infinite loop if that happens. Code that manipulates the states of data pages needs to be as robust against arbitrary on-disk states as we can reasonably make it, because pages get garbled on disk all the time. -- Robert Haas EDB: http://www.enterprisedb.com
