Hi, Various messages are discussing semantics around visibility. I by now have a hard time keeping track. So let's keep the discussion of the desired semantics to this thread.
There have been some remarks about serialization failures in read committed transactions. I agree, those shouldn't occur. But I don't actually think they are so much of a problem if we follow the path set by existing uses of the EPQ logic. The scenario described seems to be an UPSERT conflicting with a row it cannot see in the original snapshot of the query. In that case I think we just have to follow the example laid by ExecUpdate, ExecDelete and heap_lock_tuple. Use the EPQ machinery (or an alternative approach with similar enough semantics) to get a new snapshot and follow the ctid chain. When we've found the end of the chain we try to update that tuple. That surely isn't free of surprising semantics, but it would follows existing semantics. Which everybody writing concurrent applications in read committed should (but doesn't) know. Adding a different set of semantics seems like a bad idea. Robert seems to have been the primary sceptic around this, what scenario are you actually concerned about? There are some scenarios that doesn't trivially answer. But I'd like to understand the primary concerns first. Regards, Andres -- 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
