Hi Alexandre,
Thanks -- and for going with this approach. You raised two things: the
comment still described the pre-patch behavior, and it needed test
cases. Both are addressed in the attached v2:
- The comment no longer narrates the pre-patch behavior. It now says,
in the present tense, that the heap has just been rewritten and the
indexes must share that fate, and leaves the detail to
ATExecSetTableSpaceNewIndexRelfilenumber.
- There is a regression test now, in the tablespace suite. It runs
the rollback-then-reinsert sequence and checks, with seqscans off,
that the index agrees with the single live heap row -- it returns
two against the bug, where the aborted transaction's index entry
survives and aliases the reused TID. check-world is green with the
patch.
The approach is the one we settled on: after the heap move, each of the
table's indexes gets a fresh relfilenumber copied within its own
tablespace, so an abort discards the new heap and index files together.
It does not change the indexes' tablespace, matching the documented
behavior that SET TABLESPACE leaves indexes in place.
Regards,
Manu
