On Fri, Jul 28, 2023 at 8:54 PM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > On Thu, Jul 27, 2023 at 10:55 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > I wonder if we anyway some sort of design like this because we > > shouldn't allow to spawn as many workers as the number of databases. > > There has to be some existing or new GUC like max_sync_slot_workers > > which decided the number of workers. > > It seems reasonable to not have one slot sync worker for each > database. IMV, the slot sync workers must be generic and independently > manageable - generic in the sense that given a database and primary > conninfo, each worker must sync all the slots related to the given > database, independently mangeable in the sense that separate GUC for > number of sync workers, launchable directly by logical replication > launcher dynamically.
yes agreed. The patch v10-0003 attempts to do the same. > The work division amongst the sync workers can > be simple, the logical replication launcher builds a shared memory > structure based on number of slots to sync and starts the sync workers > dynamically, and each sync worker picks {dboid, slot name, conninfo} > from the shared memory, syncs it and proceeds with other slots. > Do you mean the logical replication launcher builds a shared memory structure based on the number of 'dbs' to sync as I understood from your initial comment? thanks Shveta