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? 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. I'm happy to have total scrutiny of changes to tqual.c, but I'm surprised that the mere fact of it having been modified is being weighed so heavily. Another thing that I'm not clear on is how an update can be backed out of if the row is modified by another xact. As I think I've already illustrated, the row locking that takes place has to be kind of opportunistic. I'm sure you could do it, but it would probably be quite invasive. -- 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
