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 20230914220419.GA1904031@nathanxps13
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 Wed, Sep 13, 2023 at 09:59:04AM -0700, Nathan Bossart wrote:
> On Wed, Sep 13, 2023 at 05:06:28PM +0300, Maxim Orlov wrote:
>> So, should we mark this thread as RfC?
> 
> I've done so.  Barring additional feedback, I intend to commit this in the
> next few days.

I did some staging work for the patch (attached).  The one code change I
made was for the new test.  Instead of adding a new test, I figured we
could modify the preceding test to check for the expected worker type
instead of whether relid is NULL.  ISTM this relid check is intended to
filter for the apply worker, anyway.

The only reason I didn't apply this already is because IMHO we should
adjust the worker types and the documentation for the view to be
consistent.  For example, the docs say "leader apply worker" but the view
just calls them "apply" workers.  The docs say "synchronization worker" but
the view calls them "table synchronization" workers.  My first instinct is
to call apply workers "leader apply" workers in the view, and to call table
synchronization workers "table synchronization workers" in the docs.

Thoughts?

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [PATCH] Add CANONICAL option to xmlserialize
Next
From: Peter Smith
Date:
Subject: Re: subscription TAP test has unused $result