From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Cc: | shveta malik <shveta(dot)malik(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Report bytes and transactions actually sent downtream |
Date: | 2025-09-29 07:24:24 |
Message-ID: | CAExHW5vpGQ0rBxHy-P7mmncXK-YeUihtReuR3L7nprAcyRv3YQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 26, 2025 at 10:28 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> > >
> >
> > I don't think this is an issue. There is no way for the core to tell
> > whether the plugin will provide stats or not, unless it sets that
> > ctx->stats which happens in the startup callback. Till then it is
> > rightly providing the values accumulated so far. Once the decoding
> > starts, we know that the plugin is not providing any stats and we
> > don't display anything.
>
> Yeah, I got the technical reasons, but I think there's a valid user experience
> concern here: seeing statistics for a plugin that doesn't actually support
> statistics is misleading.
>
1. If the plugin never supported statistics, we will never report
stats. So nothing misleading there.
2. If the plugin starts supporting statistics and continues to do so,
we will report the stats since the time they are made available and
continue to do so. Nothing misleading there.
3. If the plugin starts supporting statistics and midway discontinues
its support, it already has a problem with backward compatibility.
Practically it would 1 or 2, which are working fine.
I don't think we will encounter case 3 practically. Do you have a
practical use case where a plugin would discontinue supporting stats?
Even in case 3, I think we need to consider the fact that these stats
are "cumulative". So if a plugin discontinues reporting stats, they
should go NULL only when the next accumulation action happens, not
before that.
> What we need is a call to pgstat_report_replslot() to display stats that reflect
> the current plugin behavior. We can't just call pgstat_report_replslot()
> in say RestoreSlotFromDisk() because we really need the decoding to start.
>
> So one idea could be to set a flag (per slot) when pgstat_report_replslot()
> has been called (for good reasons) and check for this flag in
> pg_stat_get_replication_slot().
>
> If the flag is not set, then set the plugin fields to NULL.
> If the flag is set, then display their values (like now).
This approach will have the same problem. Till
pgstat_report_replslot() is called, the old statistics will continue
to be shown.
>
> And we should document that the plugin stats are not available (i.e are NULL)
> until the decoding has valid stats to report after startup.
After "startup" would mislead users since then they will think that
the statistics will be NULL just before the decoding (re)starts.
The current documentation is " It is NULL when statistics is not
initialized or immediately after a reset or when not maintained by the
output plugin.". I think that covers all the cases.
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Chao Li | 2025-09-29 07:29:25 | Re: Fix locking issue with fixed-size stats template in injection_points |
Previous Message | Ashutosh Bapat | 2025-09-29 06:57:18 | Re: Changing shared_buffers without restart |