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.
