Re: Design of pg_stat_subscription_workers vs pgstats
От | Masahiko Sawada |
---|---|
Тема | Re: Design of pg_stat_subscription_workers vs pgstats |
Дата | |
Msg-id | CAD21AoCJWbQ1Ehi=KimNZLXEjPvWB0PuLu6aAFqr_6Eampem2g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Design of pg_stat_subscription_workers vs pgstats ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: Design of pg_stat_subscription_workers vs pgstats
Re: Design of pg_stat_subscription_workers vs pgstats |
Список | pgsql-hackers |
On Thu, Feb 3, 2022 at 1:48 PM David G. Johnston <david.g.johnston@gmail.com> wrote: > > On Wednesday, February 2, 2022, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >> >> and have other error >> information in pg_stat_subscription_workers view. > > > What benefit is there to keeping the existing collector-based pg_stat_subscripiton_workers view? If we re-write it usingshmem IPC then we might as well put everything there and forego using a catalog. Then it behaves in a similar mannerto pg_stat_activity but for logical replication workers. Yes, but if we use shmem IPC, we need to allocate shared memory for them based on the number of subscriptions, not logical replication workers (i.e., max_logical_replication_workers). So we cannot estimate memory in the beginning. Also, IIUC the number of subscriptions that are concurrently working is limited by max_replication_slots (see ReplicationStateCtl) but I think we need to remember the state of disabled subscriptions too. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
В списке pgsql-hackers по дате отправления: