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

On Tue, Sep 2, 2025 at 10:51 AM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Friday, August 29, 2025 12:05 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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:

*
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?

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

--
With Regards,
Amit Kapila.