Re: Add 'worker_type' to pg_stat_subscription

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Maxim Orlov <orlovmg(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add 'worker_type' to pg_stat_subscription
Date: 2023-09-16 12:39:48
Message-ID: CAA4eK1JLk3zEpj0bdVXRP_xsDEGxpCpSRi72jVmxeCgHUmPBxQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 16, 2023 at 1:06 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Thu, Sep 14, 2023 at 03:04:19PM -0700, Nathan Bossart wrote:
> > 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.
>
> Concretely, like this.
>

I think there is a merit in keeping the worker type as 'sync' or
'synchronization' because these would be used in future for syncing
other objects like sequences. One more thing that slightly looks odd
is the 'leader apply' type of worker, won't this be confusing when
there is no parallel apply worker in the system? In this regard,
probably existing documentation could also be improved.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2023-09-16 17:43:47 Re: JSON Path and GIN Questions
Previous Message Michael Paquier 2023-09-16 04:18:41 Re: [PATCH] Add inline comments to the pg_hba_file_rules view