On Tue, Mar 26, 2019 at 3:23 AM Heikki Linnakangas <hlinn...@iki.fi> wrote: > Looks good. > > I started to write a patch to use XID & epoch in dealing with GiST page > deletions [1], and I really could've used an epoch to go with > RecentGlobalXmin. I presume that would be pretty straightforward to have > with this, too.
Yeah. A simple way to compute that would be to use FullTransactionId in PGXACT, so that GetSnapshotData() could find the minimum value and put that into GlobalRecentFullXmin, and set GlobalRecentXmin with the truncated version (or perhaps #define it as (XidFromFullTransactionId(GlobalRecentFullXmin))). Increasing the number of cachelines that GetSnapshotData() touches may not be popular, though. I think you could probably reclaim that space by using a more compact representation of vacuumFlags, overflowed, delayChkpt, nxids (it's funny, the comment says "as tightly as possible", which clearly isn't the case). You'd probably also need atomic 64 bit reads for the FullTransactionIds, which would be ugly on ancient systems but otherwise no problem. Instead of all that you might want to just infer the epoch instead. I'm not sure of the exact logic required for that off-hand. You'd probably want nextFullXid as a reference to compute the epoch, but you'd either need to acquire a lock to read it while you already hold ProcArrayLock (!), or read it atomically after releasing ProcArrayLock ... but then a Deathstation 9000 might allocate 8 billion more xids with all the necessary auto-vacuuming to allow that before scheduling you back onto the CPU. Admittedly, I haven't though about this very deeply at all, there may be a simple and correct way to do it. -- Thomas Munro https://enterprisedb.com