From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add 'worker_type' to pg_stat_subscription |
Date: | 2023-09-05 21:49:55 |
Message-ID: | 20230905214955.GA54303@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 06, 2023 at 09:02:21AM +1200, Peter Smith wrote:
> On Sat, Sep 2, 2023 at 7:41 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>> I see that the table refers to "leader apply workers". Would those show up
>> as parallel apply workers in the view? Can we add another worker type for
>> those?
>
> Internally there are only 3 worker types: A "leader" apply worker is
> basically the same as a regular apply worker, except it has other
> parallel apply workers associated with it.
>
> I felt that pretending there are 4 types in the view would be
> confusing. Instead, I just removed the word "leader". Now there are:
> "apply worker"
> "parallel apply worker"
> "table synchronization worker"
Okay. Should we omit "worker" for each of the types? Since these are the
values for the "worker_type" column, it seems a bit redundant. For
example, we don't add "backend" to the end of each value for backend_type
in pg_stat_activity.
I wonder if we could add the new field to the end of
pg_stat_get_subscription() so that we could simplify this patch a bit. At
the moment, a big chunk of it is dedicated to reordering the values.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2023-09-05 21:50:04 | Re: information_schema and not-null constraints |
Previous Message | Hannu Krosing | 2023-09-05 21:38:28 | Re: Initdb-time block size specification |