Re: do only critical work during single-user vacuum?
От | John Naylor |
---|---|
Тема | Re: do only critical work during single-user vacuum? |
Дата | |
Msg-id | CAFBsxsFiMPxQ-dHZ8tOgktn=+ffeJT3+GinZ4zdOGbmAnCYadA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: do only critical work during single-user vacuum? (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: do only critical work during single-user vacuum?
Re: do only critical work during single-user vacuum? |
Список | pgsql-hackers |
On Tue, Feb 15, 2022 at 11:22 AM Peter Geoghegan <pg@bowt.ie> wrote: > > On Mon, Feb 14, 2022 at 8:04 PM John Naylor > <john.naylor@enterprisedb.com> wrote: > > The failsafe mode does disable truncation as of v14: > > > > commit 60f1f09ff44308667ef6c72fbafd68235e55ae27 > > Author: Peter Geoghegan <pg@bowt.ie> > > Date: Tue Apr 13 12:58:31 2021 -0700 > > > > Don't truncate heap when VACUUM's failsafe is in effect. > > That's true, but bear in mind that it only does so when the specific > table being vacuumed actually triggers the failsafe. I believe that > VACUUM(EMERGENCY) doesn't just limit itself to vacuuming tables where > this is guaranteed (or even likely). If I'm not mistaken, it's > possible (even likely) that there will be a table whose > age(relfrozenxid) is high enough for VACUUM(EMERGENCY) to target the > table, and yet not so high that the failsafe will kick in at the > earliest opportunity. Well, the point of inventing this new vacuum mode was because I thought that upon reaching xidStopLimit, we couldn't issue commands, period, under the postmaster. If it was easier to get a test instance to xidStopLimit, I certainly would have discovered this sooner. When Andres wondered about getting away from single user mode, I assumed that would involve getting into areas too deep to tackle for v15. As Robert pointed out, lazy_truncate_heap is the only thing that can't happen for vacuum at this point, and fully explains why in versions < 14 our client's attempts to vacuum resulted in error. Since the failsafe mode turns off truncation, vacuum should now *just work* near wraparound. If there is any doubt, we can tighten the check for entering failsafe. Now, it's certainly possible that autovacuum is either not working at all because of something broken, or is not working on the oldest tables at the moment, so one thing we could do is to make VACUUM [with no tables listed] get the tables from pg_class in reverse order of max(xid age, mxid age). That way, the horizon will eventually pull back over time and the admin can optionally cancel the vacuum at some point. Since the order is harmless when it's not needed, we can do that unconditionally. -- John Naylor EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: