On Mon, Mar 23, 2020 at 04:50:36PM -0700, Andres Freund wrote: > I think there's also another (even larger?) race in > vac_update_datfrozenxid(): Unless I miss something, two backends can > concurrently run through the scan in vac_update_datfrozenxid() for two > different tables in the same database, both can check that they need to > update the pg_database row, and then one of them can overwrite the > results of the other. And the one that updates last might actually be > the one with an older horizon. This is possible since there is no 'per > database' locking in heap_vacuum_rel().
Right. This thread has a fix: https://www.postgresql.org/message-id/flat/20190218073103.GA1434723%40rfd.leadboat.com The CF entry blocking it is starting to see some activity. (Your discovery involving lastSaneFrozenXid would need a separate fix.)
