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