Re: Detecting File Damage & Inconsistencies

On 11/11/20 21:56, Simon Riggs wrote:
> [ŝnip]
>
> REINDEX VERIFY
> After the new index is created, but before we drop the old index:
> Check whether the two indexes match:
> * checks whether the previous index had pointers to row versions that
> don't exist
> * checks whether the heap has rows that were not in the old index
> This approach piggybacks on existing operations. AccessShareLock is
> held on both indexes before the old one is dropped.

FWIW, as long as it's optional (due to the added runtime), it'd be a 
welcome feature.

Maybe something along the lines of:

     REINDEX (verify yes) ....


> Other ideas are welcome.

I still have nightmares from an specific customer case w/ shared storage 
(using VxFS) among two postmaster instances ---supposedly could never be 
active concurrently, not completely sure that it didn't actually 
happen--- and the corruption that we found there. I seem to remember 
that they even had scripts to remove the locking when switching over and 
back :S

I don't think Postgres can do much about this, but maybe someone can 
come up with a suitable countermeasure.


Just my .02€

Thanks,

     / J.L.