On Sun, Sep 11, 2011 at 11:08 PM, Amit Kapila <amit.kap...@huawei.com> wrote: > In the approach mentioned in your idea, it mentioned that once after > taking snapshot, only committed XIDs will be updated and sometimes snapshot > itself. > > So when the xmin will be updated according to your idea as snapshot will > not be updated everytime so xmin cannot be latest always.
If you know what transactions were running the last time a snapshot summary was written and what transactions have ended since then, you can work out the new xmin on the fly. I have working code for this and it's actually quite simple. >>RecentGlobalXmin doesn't need to be completely up to date, and in fact > recomputing it on every snapshot becomes prohibitively expensive with this > approach. I'm still struggling with the best way to handle that. > > RecentGlobalXmin and RecentXmin are mostly updated with snapshots xmin > and that too outside ProcArrayLock, so why it will be expensive if you have > updated xmin. Because GetSnapshotData() computes a new value for RecentGlobalXmin by scanning the ProcArray. This isn't costing a whole lot extra right now because the xmin and xid fields are normally in the same cache line, so once you've looked at one of them it doesn't cost that much extra to look at the other. If, on the other hand, you're not looking at (or even locking) the ProcArray, then doing so just to recompute RecentGlobalXmin sucks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
