On Thu, Nov 14, 2019 at 12:53:53PM -0500, Tom Lane wrote:
> 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).
Well, there is also the argument of consistency. What should we do if
trying to reindex concurrently a database or a schema and that the
database or the schema include both temporary and non-temporary
tables? We cannot ignore CONCURRENTLY in this case for all the
relations if there is at least one temporary table. It could be as
well surprising to skip only a portion of temporary relations (these
with on-commit actions and issue a WARNING for each one of them, still
that would be more consistent with the treatment we do for system
catalogs in ReindexMultipleTables().
An extra solution I can think of is to not skip temporary tables with
on-commit actions, but just fallback to the non-concurrent path in
ReindexMultipleTables when reindexing each relation for any temporary
tables processed (all of them, and not just these with on-commit
actions actually).
Thoughts?
--
Michael