| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Subject: | Re: Heap lock levels for REINDEX INDEX CONCURRENTLY not quite right? |
| Date: | 2019-05-04 12:59:20 |
| Message-ID: | 20190504125920.GD4805@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-05-04 13:06:37 | Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6 |
| Previous Message | Michael Paquier | 2019-05-04 12:50:46 | Re: [Patch] Base backups and random or zero pageheaders |