Re: REINDEX CONCURRENTLY unexpectedly fails
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>,
Manuel Rigger <rigger.manuel@gmail.com>,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-11-14T17:53:53Z
Lists: 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
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