Re: Report bytes and transactions actually sent downtream

On Mon, Jul 14, 2025 at 10:55 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Sun, Jul 13, 2025 at 4:34 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> >
> > I think we don't want to make it mandatory for plugins to implement
> > these stats, so instead of throwing ERROR, the view should show that
> > the plugin doesn't provide stats. How about having OutputPluginStats
> > similar to OutputPluginCallbacks and OutputPluginOptions members in
> > LogicalDecodingContext? It will have members like stats_available,
> > txns_sent or txns_skipped, txns_filtered, etc.
>
> Not making mandatory looks useful. I can try your suggestion. Rather
> than having stats_available as a member of OutputPluginStats, it's
> better to have a NULL value for the corresponding member in
> LogicalDecodingContext. We don't want an output plugin to reset
> stats_available once set. Will that work?
>

We can try that.

> > I am thinking it will
> > be better to provide this information in a separate view like
> > pg_stat_plugin_stats or something like that, here we can report
> > slot_name, plugin_name, then the other stats we want to implement part
> > of OutputPluginStats.
>
> As you have previously pointed out, the view should make it explicit
> that the new stats are maintained by the plugin and not core. I agree
> with that intention. However, already have three views
> pg_replication_slots (which has slot name and plugin name), then
> pg_replication_stats which is about stats maintained by a WAL sender
> or running replication and then pg_stat_replication_slots, which is
> about accumulated statistics for a replication through a given
> replication slot. It's already a bit hard to keep track of who's who
> when debugging an issue. Adding one more view will add to confusion.
>
> Instead of adding a new view how about
> a. name the columns as plugin_sent_txns, plugin_sent_bytes,
> plugin_filtered_change_bytes to make it clear that these columns are
> maintained by plugin
> b. report these NULL if stats_available = false OR OutputPluginStats
> is not set in LogicalDecodingContext
> c. Document that NULL value for these columns indicates that the
> plugin is not maintaining/reporting these stats
> d. adding plugin name to pg_stat_replication_slots, that will make it
> easy for users to know which plugin they should look at in case of
> dubious or unavailable stats
>

Sounds reasonable.

--
With Regards,
Amit Kapila.