On Thursday, July 24, 2025 11:42 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Wed, Jul 23, 2025 at 12:53 PM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> >
> > On Wednesday, July 23, 2025 12:08 PM Amit Kapila
> <amit.kapila16@gmail.com> wrote:
> > >
> > > On Wed, Jul 23, 2025 at 3:51 AM Masahiko Sawada
> > > <sawada.mshk@gmail.com> wrote:
> > > >
> > > > I've reviewed the 0001 patch and it looks good to me.
> > > >
> > >
> > > Thanks, I have pushed the 0001 patch.
> >
> > Thanks for pushing. I have rebased the remaining patches.
Thanks for the comments!
> >
> > I have reordered the patches to prioritize the detection of
> > update_deleted as the initial patch. This can give us more time to
> > consider the new GUC, since the performance-related aspects have been
> documented.
> >
>
> 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?
According to the discussion[1], I kept the current behavior.
>
>
> 5)
> monitoring.sgml:
> + <para>
> + Number of times the tuple to be updated was deleted by another origin
> + during the application of changes. See <xref
> linkend="conflict-update-deleted"/>
> + for details about this conflict.
> + </para></entry>
>
> Here we are using the term 'by another origin', while in the rest of the doc (see
> confl_update_origin_differs, confl_delete_origin_differs) we use the term 'by
> another source'. Shall we keep it the same?
> OTOH, I think using 'origin' is better but the rest of the page is using source.
> So perhaps changing source to origin everywhere is better. Thoughts?
> This can be changed if needed once we decide on point 2 above.
Yes, origin may be better. But for now, I have changed to 'source' here to be
consistent with the descriptions around it, and we can improve it in a separate
patch if needed.
Other comments have been addressed in the V53 patch set.
[1] https://www.postgresql.org/message-id/CAA4eK1L09u_A0HFRydA4xc%3DHpPkCh%2B7h-%2B_WRhKw1Cksp5_5zQ%40mail.gmail.com
Best Regards,
Hou zj
