[ retrying from the email address I intended to use ] On Mon, Apr 20, 2020 at 3:42 PM Andres Freund <and...@anarazel.de> wrote: > I don't think random interspersed uses of CLogTruncationLock are a good > idea. If you move to only checking visibility after tuple fits into > [relfrozenxid, nextXid), then you don't need to take any locks here, as > long as a lock against vacuum is taken (which I think this should do > anyway).
I think it would be *really* good to avoid ShareUpdateExclusiveLock here. Running with only AccessShareLock would be a big advantage. I agree that any use of CLogTruncationLock should not be "random", but I don't see why the same method we use to make txid_status() safe to expose to SQL shouldn't also be used here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
