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. > I think it might be doable to not need either. E.g. we could set the > checking backend's xmin to relfrozenxid, and set somethign like > PROC_IN_VACUUM. That should, I think, prevent clog from being truncated > in a problematic way (clog truncations look at PROC_IN_VACUUM backends), > while not blocking vacuum. Hmm, OK, I don't know if that would be OK or not. > The similar concern for ReadNewTransactionId() can probably more easily > be addressed, by only calling ReadNewTransactionId() when encountering > an xid that's newer than the last value read. Yeah, if we can cache some things to avoid repetitive calls, that would be good. > I think it'd be good to set PROC_IN_VACUUM (or maybe a separate version > of it) while checking anyway. Reading the full relation can take quite a > while, and we shouldn't prevent hot pruning while doing so. > > There's some things we'd need to figure out to be able to use > PROC_IN_VACUUM, as that's really only safe in some > circumstances. Possibly it'd be easiest to address that if we'd make the > check a procedure... I think we sure want to set things up so that we do this check without holding a snapshot, if we can. Not sure exactly how to get there. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
