Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
От | Dilip Kumar |
---|---|
Тема | Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING |
Дата | |
Msg-id | CAFiTN-sUm2VTXO80up4n4cj3wB43dKpc+akWR6N3dRXraWmwEw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
|
Список | pgsql-hackers |
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). So if the xmax is smaller than the cutoff xid than either it is lock_only or it is aborted. If the XMAX is lock only then I don't see any issue OTOH if it is aborted xid and if it is already smaller than the cut-off xid then it is anyway live tuple. >2) it'll break HOT chain following / indexes. If my above theory in point 1 is correct then I don't see this issue as well. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: