Re: Autovacuum vs vac_update_datfrozenxid() vs ?
| От | Noah Misch |
|---|---|
| Тема | Re: Autovacuum vs vac_update_datfrozenxid() vs ? |
| Дата | |
| Msg-id | 20200402050331.GA3379102@rfd.leadboat.com обсуждение |
| Ответ на | Autovacuum vs vac_update_datfrozenxid() vs ? (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
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.)
В списке pgsql-hackers по дате отправления: