Hello! > In addition, I think the bug is not a blocker for the conflict detection > feature. As the feature simply reports the current behavior of the logical > apply worker (either unique violation or tuple missing) without introducing any > new functionality. Furthermore, I think that the new ExecCheckIndexConstraints > call after ExecInsertIndexTuples() is not affected by the dirty snapshot bug. > This is because a tuple has already been inserted into the btree before the > dirty snapshot scan, which means that a concurrent non-HOT update would not be > possible (it would be blocked after finding the just inserted tuple and wait > for the apply worker to commit the current transaction).
> It would be good if others could also share their opinion on this. Yes, you are right. At least, I can't find any scenario for that case. Best regards, Mikhail.
