Re: Add 'worker_type' to pg_stat_subscription - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Add 'worker_type' to pg_stat_subscription
Date
Msg-id 20230905214955.GA54303@nathanxps13
Whole thread Raw
In response to Re: Add 'worker_type' to pg_stat_subscription  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Add 'worker_type' to pg_stat_subscription
List 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@gmail.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



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Initdb-time block size specification
Next
From: Vik Fearing
Date:
Subject: Re: information_schema and not-null constraints