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

Поиск
Список
Период
Сортировка
От Hayato Kuroda (Fujitsu)
Тема RE: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Дата
Msg-id TYAPR01MB58663E4944DCBCCF4AD14EE0F52EA@TYAPR01MB5866.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Список pgsql-hackers
Dear Amit,

> > > > I have analyzed how we handle this. Please see attached the patch (0003)
> which
> > > > allows reusing connection.
> > > >
> > >
> > > Why did you change the application name during the connection?
> >
> > It was because the lifetime of tablesync worker is longer than slots's one and
> > tablesync worker creates temporary replication slots many times, per the target
> > relation. The name of each slots has relid, so I thought that it was not suitable.
> >
> 
> Okay, but let's try to give a unique application name to each
> tablesync worker for the purpose of pg_stat_activity and synchronous
> replication (as mentioned in existing comments as well). One idea is
> to generate a name like pg_<sub_id>_sync_<worker_slot> but feel free
> to suggest if you have any better ideas.

Good point. The slot id is passed as an argument of TablesyncWorkerMain(),
so I passed it to LogicalRepSyncTableStart(). PSA new set.

> > But in the later patch the tablesync worker tries to reuse the slot during the
> > synchronization, so in this case the application_name should be same as
> slotname.
> >
> 
> Fair enough. I am slightly afraid that if we can't show the benefits
> with later patches then we may need to drop them but at this stage I
> feel we need to investigate why those are not helping?

Agreed. Now I'm planning to do performance testing independently. We can discuss
based on that or Melih's one.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED


Вложения

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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: pgsql: Fix search_path to a safe value during maintenance operations.
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum