On Fri, Aug 2, 2024 at 10:38 PM Michail Nikolaev <michail.nikol...@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.
