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

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

In response to

Responses

Browse pgsql-bugs by date

  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