From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, 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 17:26:27 |
Message-ID: | CA+TgmoZd_wUhSsbkBa=1AJqYHV8kr2yJ3t-DbADWNbwYg4BwXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-09-14 17:55:56 | Re: Fix for parallel BTree initialization bug |
Previous Message | Tomas Vondra | 2020-09-14 17:18:56 | Re: Use incremental sort paths for window functions |