Hi, On 2019-04-16 11:38:01 -0400, Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > On 2019-Apr-16, Robert Haas wrote: > >> On Mon, Apr 15, 2019 at 9:07 PM Tom Lane <t...@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
