Re: BUG #19686: Rolling back SET TABLESPACE

Andres Freund <andres(at)anarazel(dot)de> writes:
> I don't think copying the file at commit is a good path, we shouldn't make
> commits take arbitrarily long without pretty darn good reason. I don't think
> this is that.

+1. Moving operations with a significant probability of failure into
COMMIT is also an anti-pattern.

> What about forcing indexes to be copied to a new relfilenode when copying the
> underlying table?

That seems like the logical solution to me. Nobody will be surprised
if ALTER SET TABLESPACE takes a long time for a big table; at least
not if they understand that it requires copying the data somewhere
else. Imposing costs at COMMIT time might well surprise people.

The one disadvantage I see is that (I imagine) a common use-case is
to move both a table and its indexes to a new tablespace, and this
solution will imply that that sequence double-copies the indexes.
Maybe it'd be worth providing a command variant that copies the
table and its indexes to a new tablespace in one step. But that
is a future optimization, not part of the bug fix; and I could be
wrong about whether anyone even cares.

regards, tom lane