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