Re: Report bytes and transactions actually sent downtream
От | Ashutosh Bapat |
---|---|
Тема | Re: Report bytes and transactions actually sent downtream |
Дата | |
Msg-id | CAExHW5vpGQ0rBxHy-P7mmncXK-YeUihtReuR3L7nprAcyRv3YQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Report bytes and transactions actually sent downtream (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Report bytes and transactions actually sent downtream
|
Список | pgsql-hackers |
On Fri, Sep 26, 2025 at 10:28 PM Bertrand Drouvot <bertranddrouvot.pg@gmail.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
В списке pgsql-hackers по дате отправления: