Hi,
On 2019-11-15 11:45:12 +0900, Michael Paquier wrote:
> 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().
Who said anything about skipping? What I was talking about was to
execute a non-concurrent truncate for temp tables? Given that there
never may be any relevant concurrency, and given that a non-concurrent
index build is considerably cheaper, that's a nice optimization. As well
as fixing the bug at hand?
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.
> 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).
Did you actually read the sub-thread before replying? That's literally
what we are discussing:
On 2019-11-13 11:45:34 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I wonder if we instead ought to just ignore the CONCURRENTLY when
> > targetting a temp table? That'd be a correct optimization for temp
> > tables, and would fix the issue at hand...
>
> Oh, I like that idea. Keeps applications from having to think
> about this.
That's the email you directly replied to.
Greetings,
Andres Freund