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

Поиск
Список
Период
Сортировка
От Peter Smith
Тема Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Дата
Msg-id CAHut+PtdjZVC0-F_vayByu+nCbLLeYv0R-mk3fCGtNyvvAAx_g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication  (Melih Mutlu <m.melihmutlu@gmail.com>)
Список pgsql-hackers
On Fri, Jun 23, 2023 at 11:50 PM Melih Mutlu <m.melihmutlu@gmail.com> wrote:
>
> > src/backend/replication/logical/worker.c
> >
> > 10. General -- run_tablesync_worker, TablesyncWorkerMain
> >
> > IMO these functions would be more appropriately reside in the
> > tablesync.c instead of the (common) worker.c. Was there some reason
> > why they cannot be put there?
>
> I'm not really against moving those functions to tablesync.c. But
> what's not clear to me is worker.c. Is it the places to put common
> functions for all log. rep. workers? Then, what about apply worker?
> Should we consider a separate file for apply worker too?

IIUC
- tablesync.c = for tablesync only
- applyparallelworker = for parallel apply worker only
- worker.c = for both normal apply worker, plus "common" worker code

Regarding making another file (e.g. applyworker.c). It sounds
sensible, but I guess you would need to first demonstrate the end
result will be much cleaner to get support for such a big refactor.

------
Kind Regards,
Peter Smith.
Fujitsu Australia



В списке pgsql-hackers по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: Re: Do we want a hashset type?
Следующее
От: Alena Rybakina
Дата:
Сообщение: Re: POC, WIP: OR-clause support for indexes