On Fri, Jul 25, 2025 at 2:31 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > 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. >
Agree with both the points. We can keep the current behaviour as it is. thanks Shveta