Re: Conflict detection for update_deleted in logical replication

On Fri, Jul 25, 2025 at 2:31 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Jul 25, 2025 at 12:37 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Thu, Jul 24, 2025 at 9:12 AM shveta malik <shveta(dot)malik(at)gmail(dot)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