Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?

On Sat, May 04, 2019 at 09:59:20PM +0900, Michael Paquier wrote:
> The result should be no deadlocks happening in the two sessions
> running the reindex. I can see the deadlock easily with three psql
> sessions, running manually the queries.

+ * If the OID isn't valid, it means the index as concurrently dropped,
+ * which is not a problem for us; just return normally.
Typo here s/as/is/.

I have looked closer at the patch and the change proposed looks good
to me.

Now, what do we do about the potential deadlock issues in
WaitForOlderSnapshots? The attached is an isolation test able to
reproduce the deadlock within WaitForOlderSnapshots() with two
parallel REINDEX CONCURRENTLY. I'd like to think that the best way to
do that would be to track in vacuumFlags the backends running a
REINDEX and just exclude them from GetCurrentVirtualXIDs() because
we don't actually care about missing index entries in this case like
VACUUM. But it looks also to me that is issue is broader and goes
down to utility commands which can take a lock on a table which cannot
be run in transaction blocks, hence code paths used by CREATE INDEX
CONCURRENTLY and DROP INDEX CONCURRENTLY could also cause a similar
deadlock, no?
--
Michael