Re: Add 'worker_type' to pg_stat_subscription

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add 'worker_type' to pg_stat_subscription
Date: 2023-09-18 04:01:57
Message-ID: CAA4eK1+CwqnffXihcdZCXzuahog+taZ=y=d1GeUV3NRE4o=Lbg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 18, 2023 at 6:10 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> IIUC some future feature syncing of sequences is likely to share a lot
> of the tablesync worker code (maybe it is only differentiated by the
> relid being for a RELKIND_SEQUENCE?).
>
> The original intent of this stats worker-type patch was to be able to
> easily know the type of the process without having to dig through
> other attributes (like relid etc.) to infer it.
>

That makes sense and I think it will probably be helpful in debugging.
For example, I am not sure the following and similar changes in the
patch are a good idea:
if (am_tablesync_worker())
ereport(LOG,
- (errmsg("logical replication table synchronization worker for
subscription \"%s\", table \"%s\" has started",
+ (errmsg("logical replication synchronization worker for subscription
\"%s\", table \"%s\" has started",

I think it would be sometimes helpful in debugging to know the type of
sync worker, so keeping the type in the above message would be
helpful.

> If you feel
> differentiating kinds of syncing processes won't be of interest to
> users then just generically calling it "synchronization" is fine by
> me. OTOH, if users might care what 'kind' of syncing it is, perhaps
> leaving the stats attribute as "table synchronization" (and some
> future patch would add "sequence synchronization") is better.
>

Earlier, I thought it would be better to keep it generic but after
seeing your point and the latest changes in the patch it seems
differentiating between types of sync workers would be a good idea.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2023-09-18 04:08:55 Re: Speed up transaction completion faster after many relations are accessed in a transaction
Previous Message David Rowley 2023-09-18 03:58:32 Re: make add_paths_to_append_rel aware of startup cost