From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: 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>
Subject: Re: New vacuum option to do only freezing
In-reply-to: 
 <CA+TgmoYVGqmuAQQ-dDK7WswQ5TGee8=A1V9z0oe44UHXm43bYA@mail.gmail.com>
References: <20190403.131702.71087088.horiguchi.kyotaro@lab.ntt.co.jp>
 <CAD21AoBtM=HGLkMKBgch37mf0-epa3_o=Y1PU0_m9r5YmtS-NQ@mail.gmail.com>
 <CA+Tgmoas581jpJ0TPaA38OhjXHgbLy8z1fuuHH7CaNkrboZJeA@mail.gmail.com>
 <20190404.091743.76975665.horiguchi.kyotaro@lab.ntt.co.jp>
 <CAD21AoDu0wHfBmgJSQdH4Yn1vJingqgdEQ4bUioJf8v=RQ9K=g@mail.gmail.com>
 <CA+TgmoZOJ=mPf4kedwg7HCHsG4Oimm67_3S9xEdYf=8nzO=a7w@mail.gmail.com>
 <15751.1555256860@sss.pgh.pa.us>
 <CAD21AoCZpFLC-KZywkC-K7OVp0PJKey6znaukTdTv4sEdJWQNQ@mail.gmail.com>
 <CAD21AoAjw_wTZA5vxjBM7BaOTaAHdUdCSui-MtcDwYsY1p25HA@mail.gmail.com>
 <16814.1555348381@sss.pgh.pa.us>
 <CA+TgmoYJpnbk3XP2CHkzco95a-0XfpqUeCYm74mUMh2NZX5AxA@mail.gmail.com>
 <23885.1555357618@sss.pgh.pa.us>
 <CA+TgmoZu+_-q-GFgs6vwKNj-Rs7YJmPPrX+mx5_Drgvr=QZfMA@mail.gmail.com>
 <28991.1555376836@sss.pgh.pa.us>
 <CA+TgmoYVGqmuAQQ-dDK7WswQ5TGee8=A1V9z0oe44UHXm43bYA@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 16 Apr 2019 10:26:08 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30115.1555430496.1@sss.pgh.pa.us>
Date: Tue, 16 Apr 2019 12:01:36 -0400
Message-ID: <30116.1555430496@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> 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.

Looking at heap_prepare_freeze_tuple, it looks to me like it'd notice
the problem and throw an error.  The two possible reasons for a tuple
to be dead are xmin aborted and xmax committed, right?  There are
tests in there that will complain if either of those is true and
the xid is below the freeze horizon.

Given that we don't get here except when the tuple has just become dead,
it probably is all right to assume that it can't possibly get selected
for freezing, and let those tests backstop the assumption.

(BTW, I don't understand why that code will throw "found xmin %u from
before relfrozenxid %u" if HeapTupleHeaderXminFrozen is true?  Shouldn't
the whole if-branch at lines 6113ff be skipped if xmin_frozen?)

			regards, tom lane

PS: I see that mandrill just replicated the topminnow failure that
started this discussion.