On Tue, Apr 23, 2024 at 4:53 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Mar 13, 2024 at 11:59 AM vignesh C <vignes...@gmail.com> wrote: > > > > On Wed, 13 Mar 2024 at 10:12, Zhijie Hou (Fujitsu) > > <houzj.f...@fujitsu.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. -- With Regards, Amit Kapila.
