Re: Support for REINDEX CONCURRENTLY

Hi,

I have been working a little bit more on this patch for the next
commit fest. Compared to the previous version, I have removed the part
of the code where process running REINDEX CONCURRENTLY was waiting for
transactions holding a snapshot older than the snapshot xmin of
process running REINDEX CONCURRENTLY at the validation and swap phase.
At the validation phase, there was a risk that the newly-validated
index might not contain deleted tuples before the snapshot used for
validation was taken. I tried to break the code in this area by
playing with multiple sessions but couldn't. Feel free to try the code
and break it if you can!
At the swap phase, the process running REINDEX CONCURRENTLY needed to
wait for transactions that might have needed the older index
information being swapped. As swap phase is done with an MVCC
snapshot, this is not necessary anymore.

Thanks to the removal of this code, I am not seeing anymore with this
patch deadlocks that could occur when other sessions tried to take a
ShareUpdateExclusiveLock on a relation with an ANALYZE for example. So
multiple backends can kick in parallel REINDEX CONCURRENTLY or ANALYZE
commands without risks of deadlock. Processes will just wait for locks
as long as necessary.

Regards,
--
Michael