On Tue, Oct 15, 2013 at 2:25 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-10-15 10:53:35 -0700, Peter Geoghegan wrote: >> On Tue, Oct 15, 2013 at 10:29 AM, Andres Freund <and...@2ndquadrant.com> >> wrote: >> > I think anything that only works by breaking visibility rules that way >> > is a nonstarter. Doing that from the C level is one thing, exposing it >> > this way seems a bad idea. >> >> What visibility rule is that? > > The early return you added to HTSMVCC. > > At the very least it opens you to lots of halloween problem like > scenarios.
The term "visibility rule" as you've used it here is suggestive of some authoritative rule that should obviously never even be bent. I'd suggest that what Postgres does isn't very useful as an authority on this matter, because Postgres doesn't have upsert. Besides, today Postgres doesn't just bend the rules (that is, some kind of classic notion of MVCC as described in "Concurrency Control in Distributed Database Systems" or something), it totally breaks them, at least in READ COMMITTED mode (and what I've proposed here just occurs in RC mode). It is not actually in evidence that this approach introduces Halloween problems. In order for HTSMVCC to controversially indicate visibility under my scheme, it is not sufficient for the row version to just be exclusive locked by our xact without otherwise being visible - it must also *not be updated*. Now, I'll freely admit that this could still be problematic - there might have been a subtlety I missed. But since an actual example of where this is problematic hasn't been forthcoming, I take it that it isn't obvious to either yourself or Robert that it actually is. Any scheme that involves playing cute tricks with visibility (which is to say, any credible upsert implementation) needs very careful thought. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
