On Fri, Jul 26, 2013 at 8:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> OK. I've taken care of all remaining uses of SnapshotNow in the code >> base. I think we can go ahead and remove it, now. Patch attached. > >> (And there was, hopefully, much rejoicing.) > > What about SnapshotSelf?
Well, that's still used in _bt_check_unique, unique_key_recheck (trigger function to do a deferred uniqueness check), RI_FKey_check, and rather extensively by sepgsql. I don't really have much desire to do the work to get rid of it, though. Getting rid of SnapshotNow is arguably important on the grounds that third-party code may be using it, and doing this will force them to do it the new way instead, and that's got some value. I'm not sure if anything's already been committed that relies on MVCC catalog access, but several things have certainly been proposed and it's a good bet that 9.4 will rely on the catalog access using MVCC-semantics, so forcing third-party code to stop using SnapshotNow will prevent subtle bugs. But there's no similar joy for SnapshotSelf. You can argue that all of the things that we're doing with it are crufty, but nobody's complaining about any of them, and some of them are in places where the cost of an additional MVCC snapshot on every iteration might be much more serious than anything we ever saw for catalog scans. So I'm personally content to leave it well enough alone. -- 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