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.
