Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
| От | Robert Haas |
|---|---|
| Тема | Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING |
| Дата | |
| Msg-id | CA+TgmoZd_wUhSsbkBa=1AJqYHV8kr2yJ3t-DbADWNbwYg4BwXw@mail.gmail.com обсуждение исходный текст |
| Ответ на | 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 |
On Sat, Aug 29, 2020 at 4:36 AM Dilip Kumar <dilipbalaut@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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: