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

From Peter Smith
Subject Re: Add 'worker_type' to pg_stat_subscription
Date
Msg-id CAHut+PtKo-1s8GY0didpY8JtEbyiuOOw5QSNVaA93cJb4uZU3w@mail.gmail.com
Whole thread Raw
In response to Re: Add 'worker_type' to pg_stat_subscription  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Add 'worker_type' to pg_stat_subscription
List pgsql-hackers
On Sat, Sep 2, 2023 at 7:41 AM Nathan Bossart <nathandbossart@gmail.com> wrote:

Thanks for your interest in this patch.

> Is there any reason not to spell out the names?  I think that would match
> the other system views better (e.g., backend_type in pg_stat_activity).

I had thought it might be simpler in case someone wanted to query by
type. But your suggestion for consistency is probably better, so I
changed to do it that way. The help is also simplified to match the
other 'backend_type' you cited.

> Also, instead of "tablesync worker", I'd suggest using "synchronization
> worker" to match the name used elsewhere in this table.
>

Changed to "table synchronization worker".

> 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"

PSA patch v2.

------
Kind Regards,
Peter Smith.
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: Initdb-time block size specification
Next
From: Nathan Bossart
Date:
Subject: Re: Replace known_assigned_xids_lck by memory barrier