Re: New vacuum option to do only freezing
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
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-04-16T15:25:10Z
Lists: pgsql-hackers
On Tue, Apr 16, 2019 at 11:26 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Mon, Apr 15, 2019 at 9:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > I'm not sure that's correct. If you do that, it'll end up in the > > > non-tupgone case, which might try to freeze a tuple that should've > > > been removed. Or am I confused? > > > > 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. Hmm, I think that we already choose to leave HEAPTUPLE_DEAD tuples and might freeze them if HeapTupleIsHotUpdated() || HeapTupleIsHeapOnly(L1083 at vacuumlazy.c) is true, which actually have to be deleted. What difference between these tuples and the tuples that we intentionally leave when index cleanup is disabled? Maybe I'm missing something and confused. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
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