Re: New vacuum option to do only freezing

Hi,

On 2019-04-16 11:38:01 -0400, Tom Lane wrote:
> 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.)

As I just wrote - I don't think this codepath can ever deal with tuples
that old.

Greetings,

Andres Freund