While stress testing the crash-recovery system, I keep running into wraparound shutdowns that I think should not be occurring. I go out of my way give autovac a chance to complete every now and then, more often than it should need to in order to keep up with the xid usage.
I think the problem traces down to the fact that updating pg_database.datfrozenxid is WAL logged, but updating ShmemVariableCache->oldestXid is not. So a crash at just the right time means that the databases no longer think they need to be vacuumed for wrap around, but the system as a whole thinks that they do. Should crash recovery end with the system reading the recovered pg_database and recomputing ShmemVariableCache->oldestXid ? I don't know that any non-pathological case could trigger this in production. But 2^32 is not getting any larger, while maximum common database throughput and size is. I bisect this down to f9b50b7c18c8ce7de1fee59409fe2 "Fix removal of files in pgstats directories". I think that before that commit, the leftover stats file was somehow tricking the system into vacuuming the databases more aggressively following a crash. Cheers, Jeff
