Re: Crash in new pgstats code

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

In response to

Browse pgsql-hackers by date

  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