Re: REINDEX CONCURRENTLY unexpectedly fails
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Manuel Rigger <rigger.manuel@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2020-01-14T08:47:09Z
Lists: pgsql-bugs
Hi Heikki, On Thu, Jan 09, 2020 at 12:06:19PM +0900, Michael Paquier wrote: > As the patch has been heavily modified, I am switching it back to > "Needs Review" for now and I'd like to discuss more about the lock > upgrade risks, particularly if it is considered worth the effort for > temporary relations. Thoughts are welcome. You are registered as a reviewer for this patch: https://commitfest.postgresql.org/26/2358/ Are you planning to look at it? Do you have some thoughts to share about what I wrote previously? Discarding the lock upgrade considerations is possible. Another approach would be, instead of ignoring CONCURRENTLY for temporary tables, to fail if the operation is run, and ignore these when a dabatase-wide reindex concurrently happens. This was not liked much at the beginning of the thread though. -- Michael
Commits
-
Fix concurrent indexing operations with temporary tables
- d76652edc56f 9.4.26 landed
- c39f45598177 9.5.21 landed
- ef33edeb5835 9.6.17 landed
- 9055344b495f 10.12 landed
- 5b4b07fa9ac3 11.7 landed
- 817a1b88ac66 12.2 landed
- a904abe2e284 13.0 landed