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.)