On Fri, Jul 25, 2025 at 12:37 PM shveta malik <shveta.ma...@gmail.com> wrote: > > On Thu, Jul 24, 2025 at 9:12 AM shveta malik <shveta.ma...@gmail.com> wrote: > > > > > > 2) > > + if (MySubscription->retaindeadtuples && > > + FindMostRecentlyDeletedTupleInfo(localrel, > > remoteslot, > > + > > &conflicttuple.xmin, > > + > > &conflicttuple.origin, > > + > > &conflicttuple.ts) && > > + conflicttuple.origin != replorigin_session_origin) > > + type = CT_UPDATE_DELETED; > > + else > > + type = CT_UPDATE_MISSING; > > > > Shall the conflict be detected as update_deleted irrespective of origin? > > > > On thinking more here, I think that we may have the possibility of > UPDATE after DELETE from the same origin only when a publication > selectively publishes certain operations. > > 1) > Consider a publication that only publishes UPDATE and DELETE > operations. On the publisher, we may perform operations like DELETE, > INSERT, and UPDATE. On the subscriber, only DELETE and UPDATE events > are received. In this case, should we treat the incoming UPDATE as > update_deleted or update_missing? >
If the user is doing subscription only for certain operations like Update or Delete, she may not be interested in eventual consistency as some of the data may not be replicated, so a conflict detection followed by any resolution may not be helpful. The other point is that if we report update_delete in such cases, it won't be reliable, sometimes it can be update_missing as vacuum would have removed the row, OTOH, if we report update_missing, it will always be the same conflict, and we can document it. -- With Regards, Amit Kapila.
