Re: New vacuum option to do only freezing - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: New vacuum option to do only freezing
Date
Msg-id CAD21AoADeDbE0ASbWerF1+2Cx7JT8H6fceEohxBcYQFHxRnv-A@mail.gmail.com
Whole thread Raw
In response to Re: New vacuum option to do only freezing  (Robert Haas <robertmhaas@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Autovacuum-induced regression test instability
Next
From: Tom Lane
Date:
Subject: Re: New vacuum option to do only freezing