Re: Design of pg_stat_subscription_workers vs pgstats

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Design of pg_stat_subscription_workers vs pgstats
Date: 2022-02-03 05:35:10
Message-ID: CAD21AoCJWbQ1Ehi=KimNZLXEjPvWB0PuLu6aAFqr_6Eampem2g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 3, 2022 at 1:48 PM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> On Wednesday, February 2, 2022, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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 using shmem IPC then we might as well put everything there and forego using a catalog. Then it behaves in a similar manner to 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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-02-03 06:04:14 Re: Replace pg_controldata output fields with macros for better code manageability
Previous Message Julien Rouhaud 2022-02-03 05:34:18 Re: Extensible Rmgr for Table AMs