Re: Crash in new pgstats code
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2022-04-16T22:07:17Z
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
Commits
-
pgstat: Use correct lock level in pgstat_drop_all_entries().
- 4a736a161c30 15.0 landed