RE: Avoid retaining conflict-related data when no tables are subscribed

On Thursday, September 4, 2025 7:38 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> 
> On Tue, Sep 2, 2025 at 10:51 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
> wrote:
> >
> > On Friday, August 29, 2025 12:05 PM Amit Kapila
> <amit.kapila16@gmail.com> wrote:
> > >
> > >  bool
> > > -AllTablesyncsReady(void)
> > > +AllTablesyncsReady(bool ready_if_no_tables)
> > >
> > > This change serves the purpose but I find it makes the API complex
> > > to understand because now it needs to make decisions based on
> > > different states depending on the boolean parameter passed. Can we
> > > introduce a new API for the empty subscription case?
> >
> > Added a new function HasSubscriptionRelationsCached() as suggested.
> >
> 
> Thanks, the new API looks better. I have a question related to one of the
> comments:

Thanks for the comments.

> 
> *
> Although
> +   * it seems feasible to skip all phases and directly assign
> +candidate_xid to
> +   * oldest_nonremovable_xid in the RDT_GET_CANDIDATE_XID phase
> when no
> +tables
> +   * are currently subscribed, this approach is unsafe. This is because
> +new
> +   * tables may be added to the subscription after the initial table
> +check,
> +   * requiring tuples deleted before candidate_xid for conflict
> +detection in
> +   * upcoming transactions.
> 
> --
> 
> How is it possible that new tables added will have any data (deleted data in
> this case) from a transaction prior to the candidate_xid transaction?

I initially considered the scenario where a table is created on the subscriber,
and a user deletes a row before adding the table to the subscription. Upon
reconsideration, it appears that retention is not guaranteed prior to table
addition.

However, after analyzing it further, there are some other reasons for checking
the subscription table in the final phase. The comments have been updated
accordingly to reflect the reasons. Please refer to the comments in the new
patch version for details.

> * Can we add a test to show that dead tuples are not retained even with
> retain_dead_tuples=true when subscription has no relations?

Yes, I have added a test for this.

Here is the V3 patch. I merged two patches because they
are both related to conflict data retention.

Best Regards,
Hou zj