Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
От | Andres Freund |
---|---|
Тема | Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING |
Дата | |
Msg-id | 20200915180413.olk43j7t6qq57pia@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
|
Список | pgsql-hackers |
Hi, On 2020-09-15 12:52:25 +0530, Dilip Kumar wrote: > On Tue, Sep 15, 2020 at 11:14 AM Andres Freund <andres@anarazel.de> wrote: > > > > On 2020-09-15 10:54:29 +0530, Dilip Kumar wrote: > > > What problem do you see if we set xmax to the InvalidTransactionId and > > > HEAP_XMAX_INVALID flag in the infomask ? > > > > 1) It'll make a dead tuple appear live. You cannot do this for tuples > > with an xid below the horizon. > > How is it possible? Because tuple which has a committed xmax and the > xmax is older than the oldestXmin, should not come for freezing unless > it is lock_only xid (because those tuples are already gone). There've been several cases of this in the past. A fairly easy way is a corrupted relfrozenxid (of which there are many examples). You simply cannot just assume that everything is OK and argue that that's why it's ok to fix data corruption in some approximate manner. By definition everything *is not ok* if you ever come here. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: