Re: [BUG?] check_exclusion_or_unique_constraint false negative
| От | Michail Nikolaev |
|---|---|
| Тема | Re: [BUG?] check_exclusion_or_unique_constraint false negative |
| Дата | |
| Msg-id | CANtu0ogDDQnXbrv6p7Xtc2dT_MZ1fjdPgB9-0B5Lw1b4pQGd2A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [BUG?] check_exclusion_or_unique_constraint false negative (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
RE: [BUG?] check_exclusion_or_unique_constraint false negative
|
| Список | pgsql-hackers |
Hello!
> Right, but we are extending this functionality to detect and resolve
> such conflicts [1][2]. I am hoping after that such updates won't be
> missed.
> such conflicts [1][2]. I am hoping after that such updates won't be
> missed.
Yes, this is a nice feature. However, without the DirtySnapshot index scan fix, it will fail in numerous instances, especially in master-master replication.
The update_missing feature is helpful in this case, but it is still not the correct event because a real tuple exists, and we should receive update_differ instead. As a result, some conflict resolution systems may malfunction. For example, if the resolution method is set to apply_or_skip, it will insert the new row, causing two rows to exist. This system is quite fragile, and I am sure there are many more complicated scenarios that could arise.
Best regards,
Mikhail.
В списке pgsql-hackers по дате отправления: