On Fri, Jul 26, 2013 at 9:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jul 26, 2013 at 8:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 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. > > Hm. I agree the first three may be all right, but I can't help > suspecting that sepgsql is doing the wrong thing here.
sepgsql is using SnapshotSelf to find the old version of a tuple that was updated by the core code just before. That should be safe in the sense that there can't be a currently-committing transaction somewhere else that's updated that tuple, if we know that our own uncommitted transaction has done a transactional update. There was a recent thread discussing whether another API might be better, and I'd be prepared to concede that it might be. But I don't think it's drop-dead broken. Not that I really object if someone wants to have a go at getting rid of SnapshotSelf, but I think it'd be worth articulating what we hope to accomplish by so doing. For example, the btree README says the following about the deletion algorithm: --- ... The reason we do it is to provide an interlock between non-full VACUUM and indexscans. Since VACUUM deletes index entries before deleting tuples, the super-exclusive lock guarantees that VACUUM can't delete any heap tuple that an indexscanning process might be about to visit. (This guarantee works only for simple indexscans that visit the heap in sync with the index scan, not for bitmap scans. We only need the guarantee when using non-MVCC snapshot rules; in an MVCC snapshot, it wouldn't matter if the heap tuple were replaced with an unrelated tuple at the same TID, because the new tuple wouldn't be visible to our scan anyway.) --- Obviously, when we were using SnapshotNow for catalog access, changing anything here was a non-starter. But now that we're not, it might be worth asking whether there are few enough users of non-MVCC rules that we could apply some suitable treatment to those that remain and then change the locking protocol here. And if we did do that, would there be enough performance benefit to justify the work? I don't have answers to those questions, and the answer may well be that we should leave things as they are, but I think the questions are worth thinking about. Aside from any possible advantage in further trimming the list of available snapshot types, I'd like to spend some time thinking about what we can do that's safe and useful in terms of reducing lock levels; or even adding completely new facilities that would have been DOA in the old world. I have high hopes in both areas, but I wouldn't be surprised to find that there are problems we haven't thought about yet. I think our dependence on SnapshotNow has wormed itself into our design choices in deep ways, and I suspect it's going to take a good deal of thought to figure out exactly what we can improve and how. -- 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