Hi, On 2020-09-14 13:26:27 -0400, Robert Haas wrote: > On Sat, Aug 29, 2020 at 4:36 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > 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. > > That seems reasonable to me. Andres, what do you think?
It seems pretty dangerous to me. What exactly are you going to put into xmin/xmax here? And how would anything you put into the first tuple not break index lookups? There's no such thing as a frozen xmax (so far), so what are you going to put in there? A random different xid? FrozenTransactionId? HEAP_XMAX_INVALID? This whole approach just seems likely to exascerbate corruption while also making it impossible to debug. That's ok enough if it's an explicit user action, but doing it based on a config variable setting seems absurdly dangerous to me. Greetings, Andres Freund
