Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

On Sat, Aug 29, 2020 at 1:46 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Aug 28, 2020 at 1:29 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > It can break HOT chains, plain ctid chains etc, for example. Which, if
> > earlier / follower tuples are removed can't be detected anymore at a
> > later time.
>
> I think I need a more specific example here to understand the problem.
> If the xmax of one tuple matches the xmin of the next, then either
> both values precede relfrozenxid or both follow it. In the former
> case, neither tuple should be frozen and the chain should not get
> broken; in the latter case, everything's normal anyway. If the xmax
> and xmin don't match, then the chain was already broken. Perhaps we
> are removing important evidence, though it seems like that might've
> happened anyway prior to reaching the damaged page, but we're not
> making whatever corruption may exist any worse. At least, not as far
> as I can see.

One example is, suppose during vacuum, there are 2 tuples in the hot
chain, and the xmin of the first tuple is corrupted (i.e. smaller
than relfrozenxid). And the xmax of this tuple (which is same as the
xmin of the second tuple) is smaller than the cutoff_xid while trying
to freeze the tuple. As a result, it will freeze the second tuple but
the first tuple will be left untouched.

Now, if we come for the heap_hot_search_buffer, then the xmax of the
first tuple will not match the xmin of the second tuple as we have
frozen the second tuple. But, I feel this is easily fixable right? I
mean instead of not doing anything to the corrupted tuple we can
partially freeze it? I mean we can just leave the corrupted xid alone
but mark the other xid as frozen if that is smaller then cutoff_xid.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com