Alexandre Felipe <o.alexandre.felipe@gmail.com> writes: > What if we simply block modifications to the table in a transaction > after it moved to a new tablespace?
If we were looking for a quick-n-dirty functionality-losing patch, we'd just reject ALTER SET TABLESPACE within transaction blocks. Perhaps that's the right answer for the back branches, but I'd prefer not to go that way.
Noted, but could you please address the question directly.
Currently ALTER SET TABLESPACE already locks the tables,
blocking changes to the old file, this prevents corrupted indices on
committed transactions.
What I suggested was to mirror that restriction inside the transaction,
i.e. you can't modify the table in the new tablespace during the
transaction.
We lose one feature but one could even argue that it makes the
behaviour more consistent in some sense.
It seems to me that there is consensus among the senior hackers
I see, there is a consensus that deferring file copies is
not a good trade-off and I am not pushing for that.
