Hi, On 2023-01-26 13:07:08 +0300, Aleksander Alekseev wrote: > > It *certainly* can't be right to just continue with the update in > > heap_update, > > I see no reason why. What makes this case so different from updating a > tuple created by the previous command?
To me it's a pretty fundamental violation of how heap visibility works. I'm quite sure that there will be problems, but I don't feel like investing the time to find a reproducer for something that I'm ready to reject on principle. > > as you've done. You'd have to skip the update, not execute it. What am I > > missing here? > > Simply skipping updates in a statement that literally says DO UPDATE > doesn't seem to be the behavior a user would expect. Given that we skip the update in "UPDATE", your argument doesn't hold much water. > > I think this'd completely break triggers, for example, because they won't be > > able to get the prior row version, since it won't actually be a row ever > > visible (due to cmin=cmax). > > > > I suspect it might break unique constraints as well, because we'd end up > > with > > an invisible row in part of the ctid chain. > > That's a reasonable concern, however I was unable to break unique > constraints or triggers so far: I think you'd have to do a careful analysis of a lot of code for that to hold any water. I continue to think that we should just reject this behavioural change. Greetings, Andres Freund
