Re: Support for REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support for REINDEX CONCURRENTLY
Date
Msg-id CAB7nPqSy8JMEAPSjJNBp-Gb7xpRKjc_pGYz=4P5yEb4X0VGsEg@mail.gmail.com
Whole thread Raw
In response to Re: Support for REINDEX CONCURRENTLY  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Support for REINDEX CONCURRENTLY  (Andres Freund <andres@2ndquadrant.com>)
Re: Support for REINDEX CONCURRENTLY  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Backup throttling
Next
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL PERFORM with CTE