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 19:13:09
Message-ID: 20220416191309.hj7l7y5ondq2owho@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

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.

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).

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2022-04-16 19:42:05 Re: GSoC: pgmoneta: Write-Ahead Log (WAL) infrastructure (2022)
Previous Message Tom Lane 2022-04-16 18:42:39 Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)