On Thu, Feb 8, 2018 at 8:23 PM, Peter Geoghegan <p...@bowt.ie> wrote: > Some novel new behavior -- "EPQ with a twist"-- is clearly necessary. > I feel a bit uneasy about it because anything that anybody suggests is > likely to be at least a bit arbitrary (EPQ itself is kind of > arbitrary). We only get to make a decision on how "EPQ with a twist" > will work once, and that should be a decision that is made following > careful deliberation. Ambiguity is much more likely to kill a patch > than a specific technical defect, at least in my experience. Somebody > can usually just fix a technical defect.
Here's my $0.02: I think that new concurrency errors thrown by the merge code itself deserve strict scrutiny and can survive only if they have a compelling justification, but if the merge code happens to choose an action that leads to a concurrency error of its own, I think that deserves only mild scrutiny. On that basis, of the options I listed in http://postgr.es/m/ca+tgmozdl-caukhkwet7sr7sqr0-e2t91+devhqen5sfqsm...@mail.gmail.com I like #1 least. I also dislike #4 from that list for the reasons stated there. For example, if you say WHEN MATCHED AND x.some_boolean and then WHEN MATCHED, you expect that every tuple that hits the latter clause will have that Boolean as false or null, but #4 makes that not true. I think the best options are #2 and #5 -- #2 because it's simple, and #5 because it's (maybe) more intuitive, albeit at the risk of livelock. But I'm willing to convinced of some other option; like you, I'm willing to be open-minded about this. But, as you say, we need a coherent, well-considered justification for the selected option, not just "well, this is what we implemented so you should like it". The specification should define the implementation, not the reverse. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company