Hi, Thanks for your reviews.
Hayato Kuroda (Fujitsu) <kuroda.hay...@fujitsu.com>, 13 Haz 2023 Sal, 13:06 tarihinde şunu yazdı: > 01. general > > Why do tablesync workers have to disconnect from publisher for every > iterations? > I think connection initiation overhead cannot be negligible in the postgres's > basic > architecture. I have not checked yet, but could we add a new replication > message > like STOP_STREAMING or CLEANUP? Or, engineerings for it is quite larger than > the benefit? This actually makes sense. I quickly try to do that without adding any new replication message. As you would expect, it did not work. I don't really know what's needed to make a connection to last for more than one iteration. Need to look into this. Happy to hear any suggestions and thoughts. > The sync worker sends a signal to its leader per the iteration, but it may be > too > often. Maybe it is added for changing the rstate to READY, however, it is OK > to > change it when the next change have come because > should_apply_changes_for_rel() > returns true even if rel->state == SUBREL_STATE_SYNCDONE. I think the > notification > should be done only at the end of sync workers. How do you think? I tried to move the logicalrep_worker_wakeup call from clean_sync_worker (end of an iteration) to finish_sync_worker (end of sync worker). I made table sync much slower for some reason, then I reverted that change. Maybe I should look a bit more into the reason why that happened some time. Thanks, -- Melih Mutlu Microsoft