Re: [BUG?] check_exclusion_or_unique_constraint false negative
От | Amit Kapila |
---|---|
Тема | Re: [BUG?] check_exclusion_or_unique_constraint false negative |
Дата | |
Msg-id | CAA4eK1+_V1PWXrrgAM01p+CByP6JwYRxejZrcxOu83a-v_+zZg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG?] check_exclusion_or_unique_constraint false negative (Michail Nikolaev <michail.nikolaev@gmail.com>) |
Ответы |
Re: [BUG?] check_exclusion_or_unique_constraint false negative
|
Список | pgsql-hackers |
On Fri, Aug 2, 2024 at 10:38 PM Michail Nikolaev <michail.nikolaev@gmail.com> wrote: > > > I think it is rather less likely or not possible in a parallel apply > > case because such conflicting updates (updates on the same tuple) > > should be serialized at the publisher itself. So one of the updates > > will be after the commit that has the second update. > > Glad to hear! But anyway, such logic looks very fragile to me. > > > I haven't tried the test based on your description of the general > > problem with DirtySnapshot scan. In case of logical replication, we > > will LOG update_missing type of conflict and the user may need to take > > some manual action based on that. > > Current it is just DEBUG1, so it will be probably missed by the user. > > > * XXX should this be promoted to ereport(LOG) perhaps? > > */ > > elog(DEBUG1, > > "logical replication did not find row to be updated " > > "in replication target relation \"%s\"", > > RelationGetRelationName(localrel)); > > } > 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. [1] - https://commitfest.postgresql.org/49/5064/ [2] - https://commitfest.postgresql.org/49/5021/ -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: