Re: recovering from "found xmin ... from before relfrozenxid ..." - Mailing list pgsql-hackers

From Andrey M. Borodin
Subject Re: recovering from "found xmin ... from before relfrozenxid ..."
Date
Msg-id 6521B3A8-15A8-456D-B39D-F79E793B657F@yandex-team.ru
Whole thread Raw
In response to Re: recovering from "found xmin ... from before relfrozenxid ..."  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Responses Re: recovering from "found xmin ... from before relfrozenxid ..."
List pgsql-hackers

> 27 июля 2020 г., в 09:36, Ashutosh Sharma <ashu.coek88@gmail.com> написал(а):
>
> > Also, should we try to fix VM along the way?
>
> I think we should let VACUUM do that.
Sometimes VACUUM will not get to these pages, because they are marked All Frozen.
An possibly some tuples will get stale on this page again

> > Are there any caveats with concurrent VACUUM? (I do not see any, just asking)
>
> As of now, I don't see any.
VACUUM has collection of dead item pointers. We will not resurrect any of them, right?

> > It would be good to have some checks for interrupts in safe places.
>
> I think I have already added those wherever I felt it was required. If you feel it's missing somewhere, it could be
goodif you could point it out. 
Sorry, I just overlooked that call, everything is fine here.

> > Also, I'd be happy if we had something like "Restore this tuple iff this does not break unique constraint". To do
sowe need to sort tids by xmin\xmax, to revive most recent data first. 
>
> I didn't get this point. Could you please elaborate.
You may have 10 corrupted tuples for the same record, that was updated 9 times. And if you have unique constraint on
thetable you may want to have only latest version of the row. So you want to kill 9 tuples and freeze 1. 

Thanks!

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Next
From: Dilip Kumar
Date:
Subject: Re: Parallel bitmap index scan