Re: Crash in new pgstats code
От | Andres Freund |
---|---|
Тема | Re: Crash in new pgstats code |
Дата | |
Msg-id | 20220416191309.hj7l7y5ondq2owho@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Crash in new pgstats code (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Crash in new pgstats code
Re: Crash in new pgstats code |
Список | 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 по дате отправления: