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>
Subject: Re: New vacuum option to do only freezing
In-reply-to: <20190416145434.GA23796@alvherre.pgsql>
References: <20190416145434.GA23796@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Tue, 16 Apr 2019 10:54:34 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29203.1555429081.1@sss.pgh.pa.us>
Date: Tue, 16 Apr 2019 11:38:01 -0400
Message-ID: <29204.1555429081@sss.pgh.pa.us>
Precedence: bulk

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