Re: BUG #19686: Rolling back SET TABLESPACE

Hi,

On 2026-09-16 23:06:34 +0100, Alexandre Felipe wrote:
> This patchset addresses the issue reported on the pgsql-bugs [1]
>
> The root cause is that after the relation files are copied to a new
> tablespace queries
> update the index in place but the heap is updated only in the tablespace
> copy. If
> the transaction is rolled back, the index and the heap becomes inconsistent.
>
> First I tried to fix the crash, easy for btree, manageable for hash, but
> for GiST that
> would not be feasible, AFAIK would have to perform array searches possibly
> over
> multiple pages. Later thinking about this I noticed something I didn't
> realise on my
> first read.

I think it'd also just hide corruption. That's definitely not the way to go.

> So, I decided to fix the root cause: modifying a non-durable copy of the
> file.
> I thought it would be way harder, but the code was architected well enough
> that I could save a list of deferred copies, and keep modifying the the
> table
> in place. If the transaction is rolled back all the tuples in the index
> will have
> its (possibly dead) in the heap, effectively reserving those TID, this
> prevents
> both the insertion of duplicates, and the resuscitation of dead tuples by
> later changes.

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.

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

Greetings,

Andres Freund