Re: New vacuum option to do only freezing
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: "Bossart, Nathan" <bossartn@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-01-18T20:07:50Z
Lists: pgsql-hackers
On Thu, Jan 17, 2019 at 1:57 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > The reason why I processed the tuples that became dead after the first > heap pass is that I was not sure the reason why we ignore such tuples > in the second heap pass despite of there already have been the code > doing so which has been used for a long time. I thought we can do that > in the same manner even in DISABLE_INDEX_CLEANUP case. Also, since I > thought that lazy_vacuum_page() is the best place to set them as DEAD > I modified it (In the previous patch I introduced another function > setting them as DEAD aside from lazy_vacuum_page(). But since these > were almost same I merged them). The race you're concerned about is extremely narrow. We HOT-prune the page, and then immediately afterward -- probably a few milliseconds later -- we loop over the tuples still on the page and check the status of each one. The only time we get a different answer is when a transaction aborts in those few milliseconds. We don't worry about handling those because it's a very rare condition. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Add toast-level reloption for vacuum_index_cleanup
- ce59b75d449d 12.0 landed
-
heap_prepare_freeze_tuple: Simplify coding
- 2bf372a4ae26 12.0 landed
-
Fix missing word.
- 6665305e17ed 12.0 landed
-
Allow VACUUM to be run with index cleanup disabled.
- a96c41feec6b 12.0 landed
-
Don't mark pages all-visible spuriously
- d2599ecfcc74 11.0 cited