Re: getting rid of SnapshotNow

On Fri, Jul 26, 2013 at 9:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jul 26, 2013 at 8:49 AM, Tom Lane <tgl@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