Re: BUG #19686: Rolling back SET TABLESPACE

On Tue, Sep 29, 2026 at 07:39:40PM -0400, Tom Lane wrote:
> 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.

Yes, putting the cost within the ALTER TABLE would feel less
surprising.

> 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.

And it's something that would qualify as a new feature, not really
backpatchable. At least it feels risky compared to the idea of
copying the index relfilenode.
--
Michael