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