Re: New vacuum option to do only freezing
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Masahiko Sawada <sawada.mshk@gmail.com>,
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
"Bossart,
Nathan" <bossartn@amazon.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-04-16T15:38:01Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > On 2019-Apr-16, Robert Haas wrote: >> On Mon, Apr 15, 2019 at 9:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> If we're failing to remove it, and it's below the desired freeze >>> horizon, then we'd darn well better freeze it instead, no? >> I don't know that that's safe. IIRC, the freeze code doesn't cope >> nicely with being given a tuple that actually ought to have been >> deleted. It'll just freeze it anyway, which is obviously bad. > Umm, but if we fail to freeze it, we'll leave a tuple around that's > below the relfrozenxid for the table, causing later pg_commit to be > truncated and error messages saying that the tuple cannot be read, no? Yeah. If you think that it's unsafe to freeze the tuple, then this entire patch is ill-conceived and needs to be reverted. I don't know how much more plainly I can put it: index_cleanup cannot be a license to ignore the freeze horizon. (Indeed, I do not quite see what the point of the feature is otherwise. Why would you run a vacuum with this option at all, if not to increase the table's relfrozenxid? But you can *not* advance relfrozenxid if you left old XIDs behind.) regards, tom lane
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