On Wed, 24 Apr 2024 at 15:49, Amit Kapila <amit.kapil...@gmail.com> wrote: > > 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.
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
