Hi On 2022-04-16 12:13:09 -0700, Andres Freund wrote: > 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).
I see part of a problem - in archiver stats. Even in 14 (and presumably before), we do work that can generate archiver stats (e.g. ReadCheckpointRecord()) before pgstat_reset_all(). It's not the end of the world, but doesn't seem great. But since archiver stats are fixed-numbered stats (and thus not in the hash table), they'd not trigger the backtrace we saw here. One thing that's interesting is that the failing tests have: 2022-04-15 12:07:48.828 UTC [675922][walreceiver][:0] FATAL: could not link file "pg_wal/xlogtemp.675922" to "pg_wal/00000002.history": File exists which I haven't seen locally. Looks like we have some race between startup process and walreceiver? That seems not great. I'm a bit confused that walreceiver and archiving are both active at the same time in the first place - that doesn't seem right as things are set up currently. Greetings, Andres Freund
