Re: [BUG?] check_exclusion_or_unique_constraint false negative
| От | Michail Nikolaev |
|---|---|
| Тема | Re: [BUG?] check_exclusion_or_unique_constraint false negative |
| Дата | |
| Msg-id | CANtu0oh69b+VCiASX86dF_eY=9=A2RmMQ_+0+uxZ_Zir+oNhhw@mail.gmail.com обсуждение исходный текст |
| Ответ на | RE: [BUG?] check_exclusion_or_unique_constraint false negative ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
| Ответы |
Re: [BUG?] check_exclusion_or_unique_constraint false negative
|
| Список | pgsql-hackers |
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).
> 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.
В списке pgsql-hackers по дате отправления: