Re: New vacuum option to do only freezing
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Masahiko Sawada <sawada.mshk@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "Bossart, Nathan" <bossartn@amazon.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-02T14:28:30Z
Lists: pgsql-hackers
Hi, On 2019-05-02 10:20:25 -0400, Robert Haas wrote: > On Tue, Apr 16, 2019 at 12:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > So after thinking about this a bit more ... > > 2. Act as if the tuple were still live, just as would've happened if the > > state didn't change till just after we looked instead of just before. > > > > Option #2 is a lot simpler and safer, and can be implemented as I > > suggested earlier, assuming we're all good with the assumption that > > heap_prepare_freeze_tuple isn't going to do anything bad. > > After studying this more carefully, I agree. You and Andres and > Alvaro are all correct, and I'm plain wrong. Thanks for explaining. > I have committed a patch that changes the logic as per your > suggestion, and also removes nleft_dead_tuples and nleft_dead_itemids. It'd be good if somebody could make a pass over the safety mechanisms in heap_prepare_freeze_tuple(). I added them at some point, after a data corrupting bug related to freezing, but they really were more intended as a secondary layer of defense, rather than the primary one. My understanding is still that we assume that we never should reach heap_prepare_freeze_tuple() for something that is below the horizon, even after this change, right? Greetings, Andres Freund
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