Re: REINDEX CONCURRENTLY unexpectedly fails - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: REINDEX CONCURRENTLY unexpectedly fails
Date
Msg-id 20191115080706.GI1849@paquier.xyz
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY unexpectedly fails  (Michael Paquier <michael@paquier.xyz>)
Responses Re: REINDEX CONCURRENTLY unexpectedly fails  (Michael Paquier <michael@paquier.xyz>)
Re: REINDEX CONCURRENTLY unexpectedly fails  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
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

Attachment

pgsql-bugs by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: BUG #16116: function lpad(integer, integer, integer) does not exist
Next
From: Juan José Santamaría Flecha
Date:
Subject: Re: BUG #16108: Colorization to the output of command-line hasunproperly behaviors at Windows platform