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.