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

From Tom Lane
Subject Re: REINDEX CONCURRENTLY unexpectedly fails
Date
Msg-id 3808.1573754033@sss.pgh.pa.us
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>)
List pgsql-bugs
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Nov 13, 2019 at 11:45:34AM -0500, Tom Lane wrote:
>> Oh, I like that idea.  Keeps applications from having to think
>> about this.

> That's interesting, but I would be on the side of just generating an
> error in this case thinking about potential future features like
> global temporary tables, and because it could always be relaxed in the
> future.

I don't find that very convincing.  If there's a reason to throw
error for global temporary tables, let's do it for that case,
but that's no reason to make the user-visible behavior overcomplex
for other cases.  It might well be that we can handle global temp
tables the same way anyway (ie, just do a not-CONCURRENTLY reindex
on the session's private instance of the table).

> I am actually wondering if we don't have more problems with other
> utility commands which spawn multiple transactions...

Indeed, but there aren't many of those...

            regards, tom lane



pgsql-bugs by date:

Previous
From: Palle Girgensohn
Date:
Subject: postgresql12-plpython: python3.6m crash database after ssh sessionclose
Next
From: PG Bug reporting form
Date:
Subject: BUG #16115: Package postgresql12-12.1 is not signed