Re: Add 'worker_type' to pg_stat_subscription

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(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:02:21
Message-ID: CAHut+PtKo-1s8GY0didpY8JtEbyiuOOw5QSNVaA93cJb4uZU3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 2, 2023 at 7:41 AM Nathan Bossart <nathandbossart(at)gmail(dot)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 Content-Type Size
v2-0001-Add-worker_type-to-pg_stat_subscription.patch application/x-patch 6.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-09-05 21:08:29 Re: Replace known_assigned_xids_lck by memory barrier
Previous Message David Christensen 2023-09-05 20:57:06 Re: Initdb-time block size specification