Re: REINDEX CONCURRENTLY unexpectedly fails
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Manuel Rigger <rigger.manuel@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-11-15T08:07:06Z
Lists: pgsql-bugs
Attachments
- reindex-conc-temp-v1.patch (text/x-diff) patch v1
On Fri, Nov 15, 2019 at 12:21:41PM +0900, Michael Paquier wrote: > On Thu, Nov 14, 2019 at 06:54:12PM -0800, Andres Freund wrote: >> I think it'd be really user hostile if ReindexMultipleTables() suddenly >> started to error out if there were any temp tables. That clearly can't >> be an option. > > Okay. So, here is a patch to address all that. I have also added a test for REINDEX SCHEMA on a temporary schema. While looking at the problem, I have found a crash if trying to reindex concurrently an index or a table using a temporary relation from a different session because we have been lacking checks with RELATION_IS_OTHER_TEMP() in the concurrent code paths. For a schema or database reindex this was not happening as these are filtered out using isTempNamespace(). Please note that I have not changed index_drop() for the concurrent mode. Per my checks this does not actually cause any direct bugs as this code path just takes care of dropping the dependencies with the index. There could be an argument for changing that on HEAD though, but I am not sure that this is worth the complication either. -- 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