Re: Conflict detection for update_deleted in logical replication

On Fri, Jul 25, 2025 at 12:37 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Thu, Jul 24, 2025 at 9:12 AM shveta malik <shveta.malik@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.