Re: BUG #18046: stats collection behaviour change is affecting the usability of information.

Hi,

On 2023-09-06 13:06:35 -0400, Bruce Momjian wrote:
> (This email has Andres properly in the TO field.)
> 
> Andres, can you comment on this thread?  I see you had a commit to PG
> 15 in this area:
> 
>     commit 5cd1c40b3c
>     Author: Andres Freund <andres@anarazel.de>
>     Date:   Thu Apr 14 17:40:25 2022 -0700
>     
>         pgstat: set timestamps of fixed-numbered stats after a crash.
>     
>         When not loading stats at startup (i.e. pgstat_discard_stats() getting
>         called), reset timestamps of fixed numbered stats would be left at
>         0. Oversight in 5891c7a8ed8.
>     
>         Instead use pgstat_reset_after_failure() and add tests verifying that
>         fixed-numbered reset timestamps are set appropriately.
>     
>         Reported-By: "David G. Johnston" <david.g.johnston@gmail.com>
>         Discussion: https://postgr.es/m/CAKFQuwamFuaQHKdhcMt4Gbw5+Hca2UE741B8gOOXoA=TtAd2Yw@mail.gmail.com
> 
> Thanks.

I don't think that commit is relevant, but I still am to blame :)


> On Fri, Aug  4, 2023 at 10:40:46PM +0530, Jobin Augustine wrote:
> > Thank you Hamid for working on this and coming with a fix.
> >     Attach is a fix for PG16 and PG15 that resolves this issue. It ensures that
> >     when the database stats are being written to disk and the stats_reset is
> >     not set, it adds the current timestamp to it. Since a new file is written
> >     at initdb and when the server is recovering from a crash, this works as
> >     expected.

I don't think that's the right approach. This way we'll end up with a stats
reset time that can be *after* other stats have already accumulated. Which
doesn't seem great.

I think Horiguchi-san's approach is closer to what we would want.


Unfortunately, the reset time for other variable-numbered stats entries
historically has behaved differently than what you're
desiring. E.g. pg_stat_replication_slots.stats_reset isn't set unless you have
reset the stats.

I'm ok with changing the semantics to one behaviour, but I'm a bit hesitant
whacking this around further in a minor release...

Greetings,

Andres Freund