Re: do only critical work during single-user vacuum?
От | Peter Geoghegan |
---|---|
Тема | Re: do only critical work during single-user vacuum? |
Дата | |
Msg-id | CAH2-Wznb+W7HdrcT7vLe5hvxA131ay2EwdY+r3z8Uehd_Jr5uw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: do only critical work during single-user vacuum? (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: do only critical work during single-user vacuum?
|
Список | pgsql-hackers |
On Wed, Feb 16, 2022 at 8:48 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > FYI, I've tested the situation that I assumed autovacuum can not > correct the problem; when the system had already crossed xidStopLimit, > it keeps failing to vacuum on tables that appear in the front of the > list and have sufficient garbage to trigger the truncation but are not > older than the failsafe limit. But contrary to my assumption, it did > correct the problem since autovacuum continues to the next table in > the list even after an error. This probably means that autovacuum > eventually succeeds to process all tables that trigger the failsafe > mode, ensuring advancing datfrozenxid, which is great. Right; it seems as if the situation is much improved, even when the failsafe didn't prevent the system from going over xidStopLimit. If autovacuum alone can bring the system back to a normal state as soon as possible, without a human needing to do anything special, then clearly the general risk is much smaller. Even this worst case scenario where "the failsafe has failed" is not so bad anymore, in practice. I don't think that it really matters if some concurrent non-emergency VACUUMs fail when attempting to truncate the table (it's no worse than ANALYZE failing, for example). Good news! -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: