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. > Upsert *has* to do effectively the same thing as what I've proposed - > there is no getting away from it. So maybe the visibility rulebook > (which as far as I can tell is "the way things work today") needs to > be updated. If we did, say, INSERT...ON DUPLICATE KEY UPDATE, we'd > have to update a row with potentially no visible-to-snapshot version > *at all*, and make a new version of that visible. That's just what it > takes. What's the difference between that and just locking? If the > only difference is that it isn't necessary to modify tqual.c because > you're passing a tid directly, that isn't a user-visible difference - > the "rule" has been broken just the same. Arguably, it's even more of > a hack, since it's a special, out-of-band visibility exception. No, doing it in special case code is fundamentally different since those locations deal only with one row at a time. There's no scans that can pass over that row. That's why I think exposing the "on conflict lock" logic to anything but C isn't going to fly btw. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
