On Tue, Jan 3, 2012 at 1:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >>> Another point that requires some thought is that switching SnapshotNow >>> to be MVCC-based will presumably result in a noticeable increase in each >>> backend's rate of wanting to acquire snapshots. > > BTW, I wonder if this couldn't be ameliorated by establishing some > ground rules about how up-to-date a snapshot really needs to be. > Arguably, it should be okay for successive SnapshotNow scans to use the > same snapshot as long as we have not acquired a new lock in between. > If not, reusing an old snap doesn't introduce any race condition that > wasn't there already.
Is that likely to help much? I think our usual pattern is to lock the catalog, scan it, and then release the lock, so there will normally be an AcceptInvalidationMessages() just before the scan. Or at least, I think there will. Another thought is that it should always be safe to reuse an old snapshot if no transactions have committed or aborted since it was taken (possibly we could narrow that to "no transactions have committed since it was taken", but I think that might cause some headaches with RecentGlobalXmin). I wonder if we could come up with a cheap, hopefully lock-free method of determining whether or not that's the case. For example, suppose we store the last XID to commit or abort in shared memory. In GetSnapshotData(), we check whether that value has changed (probably, after enforcing a memory barrier of some kind) before acquiring the lock. If it has, we proceed normally, but if not, we just reuse the results from the previous GetSnapshotData(). -- 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
