From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Crash in new pgstats code |
Date: | 2022-04-16 22:07:17 |
Message-ID: | 20220416220717.ciuzeuioskuhc5a4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-04-16 12:13:09 -0700, Andres Freund wrote:
> On 2022-04-15 13:28:35 -0400, Tom Lane wrote:
> > mylodon just showed a new-to-me failure mode [1]:
>
> Thanks. Found the bug (pgstat_drop_all_entries() passed the wrong lock
> level), with the obvious fix.
>
> This failed to fail in other tests because they all end up resetting
> only when there's no stats. It's not too hard to write a test for that,
> which is how I reproduced the issue.
>
> I'm planning to make it a bit easier to test by verifying that 'E' in
> pgstat_read_statsfile() actually is just before EOF. That seems like a
> good check anyway.
I've pushed that fix.
> What confuses me so far is what already had generated stats before
> reaching pgstat_reset_after_failure() (so that the bug could even be hit
> in t/025_stuck_on_old_timeline.pl).
But there's still things I don't understand about that aspect.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-04-17 00:30:28 | Re: convert libpq uri-regress tests to tap test |
Previous Message | Andres Freund | 2022-04-16 21:36:33 | Re: Crash in new pgstats code |