| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, 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-07 23:43:11 |
| Message-ID: | 20190507234311.GA2223@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, May 07, 2019 at 06:45:36PM -0400, Tom Lane wrote:
> Yeah. CREATE INDEX CONCURRENTLY has always had a deadlock hazard,
> so it's hardly surprising that REINDEX CONCURRENTLY does too.
> I don't think that fixing that is in-scope for v12, even if we had
> an idea how to do it, which we don't.
The most straight-forward approach I can think of would be to
determine if non-transactional commands taking a lock on a table can
be safely skipped or not when checking for older snapshots than the
minimum where the index is marked as valid. That's quite complex to
target v12, so I agree to keep it out of the stability work.
> We do need to fix the wrong-lock-level problem of course, but
> that seems straightforward.
Sure.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-05-07 23:44:31 | Re: Why could GEQO produce plans with lower costs than the standard_join_search? |
| Previous Message | Donald Dong | 2019-05-07 23:29:04 | Why could GEQO produce plans with lower costs than the standard_join_search? |