Re: recovering from "found xmin ... from before relfrozenxid ..."

> > 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
>

Hmm, okay, will have a look into this. Thanks.


>
> > > 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?
>

We won't be doing any such things.


> > > 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 good if you could point it out.
> Sorry, I just overlooked that call, everything is fine here.
>

Okay, thanks for confirming.


> > > Also, I'd be happy if we had something like "Restore this tuple iff
> this does not break unique constraint". To do so we 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 the table you may want to have
> only latest version of the row. So you want to kill 9 tuples and freeze 1.
>

Okay, in that case, users need to pass the tids of the 9 tuples that they
want to kill to heap_force_kill function and the tid of the tuple that they
want to be marked as frozen to heap_force_freeze function. Just to inform
you that this tool is not used to detect any data corruption, it is just
meant to remove/clean the corrupted data in a table so that the operations
like vacuum, pg_dump/restore succeeds. It's users responsibility to
identify the corrupted data and pass its tid to either of these functions
as per the requirement.

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com