On Tue, Jan 30, 2018 at 8:56 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> Peter is arguing >> that we don't normally issue a serialization error at READ COMMITTED >> (which I think is true) and proposed that we instead try to INSERT. > > Which IMHO is case 4 since it would avoid a concurrent ERROR.
It would avoid the error that you added in v13 of your patch, a type of error that I never proposed or even considered. > This meets exactly my original implementation goals as clearly stated on > this thread I'm glad that you see it that way. I didn't and don't, though I objected to your characterization mostly because it muddied some already rather muddy waters. I'm happy to let it go now, though. > If you now agree with doing that and are happy that there are no > dangers, then I'm happy we now have consensus again and we can > continue implementing MERGE for PG11. My outline from earlier today about EPQ handling, and how it needs to deal with multiple independent sets of WHEN ... AND quals is, as I said, very tentative. There isn't even consensus in my own mind about this, much less between everyone that has taken an interest in this project. I'm glad that we all seem to agree that serialization failures as a way of dealing with concurrency issues in READ COMMITTED mode are a bad idea. Unfortunately, I still think that we have a lot of work ahead of us when it comes to agreeing to the right semantics with READ COMMITTED conflict handling with multiple WHEN ... AND quals. I see that your v14 still has the serialization error, even though it's now clear that nobody wants to go that way. So...where do we go from here? (For the avoidance of doubt, this is *not* a rhetorical question.) -- Peter Geoghegan
