On Sat, Aug 29, 2020 at 1:46 AM Robert Haas <robertmh...@gmail.com> wrote: > > On Fri, Aug 28, 2020 at 1:29 PM Andres Freund <and...@anarazel.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
