| From: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
|---|---|
| To: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: [BUG?] check_exclusion_or_unique_constraint false negative |
| Date: | 2024-08-16 13:31:55 |
| Message-ID: | CANtu0oh69b+VCiASX86dF_eY=9=A2RmMQ_+0+uxZ_Zir+oNhhw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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).
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2024-08-16 14:37:06 | Re: Make query cancellation keys longer |
| Previous Message | Thomas Munro | 2024-08-16 13:12:43 | Re: thread-safety: gmtime_r(), localtime_r() |