| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #19686: Rolling back SET TABLESPACE |
| Date: | 2026-10-02 18:55:27 |
| Message-ID: | 1383373.1790967327@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> I wonder if we should try to apply two optimizations, even in the back
> branches:
> 1) don't copy indexes if the SET TABLESPACE is executed at the top-level
> 2) Avoid the index copy if the index has been created in the current
> subtransaction.
+1 to both things, doesn't seem too difficult. (1) probably covers
the majority of existing usage --- else, we'd have noticed this
problem a long time ago.
>> 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.
> With the 2) from above, that could then be achieved by having a transaction
> first move the indexes and then the table itself. Probably not as good as a
> command doing both, but it can be done without a new syntax...q
Agreed, that at least provides a workaround.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manu | 2026-10-02 19:34:18 | Re: BUG #19686: Rolling back SET TABLESPACE |
| Previous Message | Andres Freund | 2026-10-02 18:52:14 | Re: BUG #19686: Rolling back SET TABLESPACE |