Re: Avoid retaining conflict-related data when no tables are subscribed - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Avoid retaining conflict-related data when no tables are subscribed
Date
Msg-id CAA4eK1+c=sWY2xkAS9f5B1qvT_EFNWYi=c2SNhxmbZ=ob6EsjQ@mail.gmail.com
Whole thread Raw
In response to RE: Avoid retaining conflict-related data when no tables are subscribed  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Responses RE: Avoid retaining conflict-related data when no tables are subscribed
List pgsql-hackers
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:

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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Generate GUC tables from .dat file
Next
From: Álvaro Herrera
Date:
Subject: Re: Potential problem in commit f777d773878 and 4f7f7b03758