On Fri, Aug 11, 2023 at 2:29 PM Peter Smith <smithpb2...@gmail.com> wrote: > > While reviewing other threads I have been looking more closely at the > the logicalrep_worker_launch() function. IMO the logic of that > function seems not quite right. > > Here are a few things I felt are strange: > ... > > 2. There is some condition for attempting the garbage-collection of workers: > > /* > * If we didn't find a free slot, try to do garbage collection. The > * reason we do this is because if some worker failed to start up and its > * parent has crashed while waiting, the in_use state was never cleared. > */ > if (worker == NULL || nsyncworkers >= max_sync_workers_per_subscription) > > The inclusion of that nsyncworkers check here has very subtle > importance. AFAICT this means that even if we *did* find a free > worker, we still need to do garbage collection just in case one of > those 'in_use' tablesync worker was in error (e.g. crashed after > marked in_use). By garbage-collecting (and then re-counting > nsyncworkers) we might be able to launch the tablesync successfully > instead of just returning that it has maxed out. > > 2a. IIUC that is all fine. The problem is that I think there should be > exactly the same logic for the parallel apply workers here also. >
Did you try to reproduce this condition, if not, can you please try it once? I wonder if the leader worker crashed, won't it lead to a restart of the server? -- With Regards, Amit Kapila.
