From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING |
Date: | 2020-09-14 18:39:05 |
Message-ID: | 20200914183905.bbkn5unr7txk66pk@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-09-14 13:26:27 -0400, Robert Haas wrote:
> On Sat, Aug 29, 2020 at 4:36 AM Dilip Kumar <dilipbalaut(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2020-09-14 18:53:48 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
Previous Message | Tom Lane | 2020-09-14 18:33:53 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |