On Mon, Apr 20, 2020 at 1:40 PM Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Apr 20, 2020 at 4:30 PM Andres Freund <and...@anarazel.de> wrote: > > A few billion CLogTruncationLock acquisitions in short order will likely > > have at least as big an impact as ShareUpdateExclusiveLock held for the > > duration of the check. That's not really a relevant concern or > > txid_status(). Per-tuple lock acquisitions aren't great. > > Yeah, that's true. Doing it for every tuple is going to be too much, I > think. I was hoping we could avoid that.
What about the visibility map? It would be nice if pg_visibility was merged into amcheck, since it mostly provides integrity checking for the visibility map. Maybe we could just merge the functions that perform verification, and leave other functions (like pg_truncate_visibility_map()) where they are. We could keep the current interface for functions like pg_check_visible(), but also allow the same verification to occur in passing, as part of a higher level check. It wouldn't be so bad if pg_visibility was an expert-only tool. But ISTM that the verification performed by code like collect_corrupt_items() could easily take place at the same time as the new checks that Mark proposes. Possibly only some of the time. It can work in a totally additive way. (Though like Andres I don't really like the current "helper" functions used to iterate through a heap relation; they seem like they'd make this harder.) -- Peter Geoghegan
