Re: Race condition in FetchTableStates() breaks synchronization of subscription tables - Mailing list pgsql-hackers

From vignesh C
Subject Re: Race condition in FetchTableStates() breaks synchronization of subscription tables
Date
Msg-id CALDaNm11WrpFaT3rf263fj6c6vf4Q4tPR_8o3AEEMPyRwwEjrQ@mail.gmail.com
Whole thread Raw
In response to Re: Race condition in FetchTableStates() breaks synchronization of subscription tables  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: Race condition in FetchTableStates() breaks synchronization of subscription tables
List pgsql-hackers
On Wed, 24 Apr 2024 at 11:59, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Mar 13, 2024 at 9:19 AM vignesh C <vignesh21@gmail.com> wrote:
> >
> > On Tue, 12 Mar 2024 at 09:34, Ajin Cherian <itsajin@gmail.com> wrote:
> > >
> > >
> > >
> > > On Tue, Mar 12, 2024 at 2:59 PM vignesh C <vignesh21@gmail.com> wrote:
> > >>
> > >>
> > >> Thanks, I have created the following Commitfest entry for this:
> > >> https://commitfest.postgresql.org/47/4816/
> > >>
> > >> Regards,
> > >> Vignesh
> > >
> > >
> > > Thanks for the patch, I have verified that the fix works well by following the steps mentioned to reproduce the
problem.
> > > Reviewing the patch, it seems good and is well documented. Just one minor comment I had was probably to change
thename of the variable table_states_valid to table_states_validity. The current name made sense when it was a bool,
butnow that it is a tri-state enum, it doesn't fit well. 
> >
> > Thanks for reviewing the patch, the attached v6 patch has the changes
> > for the same.
> >
>
> v6_0001* looks good to me. This should be backpatched unless you or
> others think otherwise.

This patch needs to be committed in master,PG16 and PG15.
This is not required from PG14 onwards because they don't have
HasSubscriptionRelations call before updating table_states_valid:
    /*
     * Does the subscription have tables?
     *
     * If there were not-READY relations found then we know it does. But
     * if table_states_not_ready was empty we still need to check again to
     * see if there are 0 tables.
     */
    has_subrels = (table_states_not_ready != NIL) ||
      HasSubscriptionRelations(MySubscription->oid);

So the invalidation function will not be called here.

Whereas for PG15 and newer versions this is applicable:
HasSubscriptionRelations calls table_open function which will get the
invalidate callback like in:
HasSubscriptionRelations -> table_open -> relation_open ->
LockRelationOid -> AcceptInvalidationMessages ->
ReceiveSharedInvalidMessages -> LocalExecuteInvalidationMessage ->
CallSyscacheCallbacks -> invalidate_syncing_table_states

The attached patch
v7-0001-Table-sync-missed-due-to-race-condition-in-subscr.patch
applies for master and PG16 branch,
v7-0001-Table-sync-missed-due-to-race-condition-in-subscr_PG15.patch
applies for PG15 branch.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Race condition in FetchTableStates() breaks synchronization of subscription tables
Next
From: Peter Eisentraut
Date:
Subject: Re: doc: create table improvements