Re: Crash in new pgstats code - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Crash in new pgstats code
Date
Msg-id 20220416191309.hj7l7y5ondq2owho@alap3.anarazel.de
Whole thread Raw
In response to Crash in new pgstats code  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Crash in new pgstats code  (Andres Freund <andres@anarazel.de>)
Re: Crash in new pgstats code  (Andres Freund <andres@anarazel.de>)
List 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



pgsql-hackers by date:

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