Re: Add 'worker_type' to pg_stat_subscription

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

In response to

Responses

Browse pgsql-hackers by date

  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