Re: Design of pg_stat_subscription_workers vs pgstats
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
"David G. Johnston" <david.g.johnston@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-02-23T03:47:31Z
Lists: pgsql-hackers
On Tue, Feb 22, 2022 at 8:02 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Tue, Feb 22, 2022 at 6:53 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > 3. Can we send error stats pgstat_report_stat() as that will be called > > via proc_exit() path. We can set the phase (apply/sync) in > > apply_error_callback_arg and then use that to send the appropriate > > message. I think this will obviate the need for try..catch. > > If we use pgstat_report_stat() to send subscription stats messages, > all processes end up going through that path. It might not bring > overhead in practice but I'd like to avoid it. > I am not sure about overhead but I see another problem if we use that approach. In the exit path, logicalrep_worker_onexit() will get called before pgstat_report_stat() and that will clear the MyLogicalRepWorker->subid, so we won't know the id for which to send stats. So, the way patch is doing seems reasonable to me unless someone has better ideas. -- With Regards, Amit Kapila.
Commits
-
Reconsider pg_stat_subscription_workers view.
- 7a8507329085 15.0 landed
-
Add a view to show the stats of subscription workers.
- 8d74fc96db5f 15.0 cited