Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication

Hi,

Thanks for your reviews.

Hayato Kuroda (Fujitsu) <kuroda(dot)hayato(at)fujitsu(dot)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