Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?
Date
Msg-id 20190504125920.GD4805@paquier.xyz
Whole thread Raw
In response to Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?  (Andres Freund <andres@anarazel.de>)
Responses Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right?  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Fri, May 03, 2019 at 08:23:21AM -0700, Andres Freund wrote:
> I've not tested the change, but it looks reasonable to me. The change
> of moving the logic the reset of *heapOid to the unlock perhaps is
> debatable, but I think it's OK.

I have not checked the patch in details yet, but it strikes me that
we should have an isolation test case which does the following:
- Take a lock on the table created, without committing yet the
transaction where the lock is taken.
- Run two REINDEX CONCURRENTLY in two other sessions.
- Commit the first transaction.
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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [Patch] Base backups and random or zero pageheaders
Next
From: Michael Paquier
Date:
Subject: Re: REINDEX INDEX results in a crash for an index of pg_class since9.6