Re: [BUG?] check_exclusion_or_unique_constraint false negative
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Michail Nikolaev <michail.nikolaev@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>
Date: 2024-08-05T10:16:20Z
Lists: 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.
Commits
-
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
- 168d5805e4c0 9.5.0 cited