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.
