From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Hamid Akhtar <hamid(dot)akhtar(at)percona(dot)com>, jobinau(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Jobin Augustine <jobin(dot)augustine(at)percona(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Subject: | Re: BUG #18046: stats collection behaviour change is affecting the usability of information. |
Date: | 2023-09-14 03:30:05 |
Message-ID: | 20230914033005.q4uqy4uylwjgfbev@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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(at)anarazel(dot)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(dot)g(dot)johnston(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Lepikhov Andrei | 2023-09-14 04:58:39 | Re: EXPLAIN Verbose issue - custom_scan_tlist can directly refer CTE and Subquery |
Previous Message | Laurenz Albe | 2023-09-14 02:52:58 | Re: Segmentation Fault |