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
