Re: Race condition in FetchTableStates() breaks synchronization of subscription tables

On Wed, 24 Apr 2024 at 15:49, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, Apr 23, 2024 at 4:53 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Wed, Mar 13, 2024 at 11:59 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > >
> > > On Wed, 13 Mar 2024 at 10:12, Zhijie Hou (Fujitsu)
> > > <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > > >
> > > >
> > > > For 0002, instead of avoid resetting the latch, is it possible to let the
> > > > logical rep worker wake up the launcher once after attaching ?
> > >
> > > Waking up of the launch process uses the same latch that is used for
> > > subscription creation/modification and apply worker process exit. As
> > > the handling of this latch for subscription creation/modification and
> > > worker process exit can be done only by ApplyLauncherMain, we will not
> > > be able to reset the latch in WaitForReplicationWorkerAttach. I feel
> > > waking up the launcher process might not help in this case as
> > > currently we will not be able to differentiate between worker
> > > attached, subscription creation/modification and apply worker process
> > > exit.
> > >
> >
> > IIUC, even if we set the latch once the worker attaches, the other
> > set_latch by subscription creation/modification or apply_worker_exit
> > could also be consumed due to reset of latch in
> > WaitForReplicationWorkerAttach(). Is that understanding correct? If
> > so, can we use some other way to wake up
> > WaitForReplicationWorkerAttach() say condition variable?
> >
>
> The other possibility is to have a GUC launcher_retry_time or
> something like that instead of using a DEFAULT_NAPTIME_PER_CYCLE. This
> still may not resolve the issue if launcher_retry_time is longer but
> at least users would be able to configure it. I am not sure if this is
> a good idea or not but just trying to brainstorm different ideas to
> solve this problem.
>
> BTW, as far as I understand, this is an improvement in the existing
> code, so should be done only for HEAD (probably PG18) and should be
> discussed in a separate thread.

I have started a new thread at [1] to discuss this:
https://www.postgresql.org/message-id/CALDaNm01_KEgHM1tKtgXkCGLJ5209SMSmGw3UmhZbOz365_%3DeA%40mail.gmail.com

Regards,
Vignesh