Thank you Manu, Again talking about past,
I am insisting on this point, I don't see the codebase talking about past bugs, the test just describes the correct behaviour. +-- With seqscans disabled this count is answered from the index; it must match +-- the single live heap row (it returns 2 against the bug, where the aborted +-- transaction's index entry survives and aliases the reused TID). If we are recreating the indices, a better way to observe the effect is by inserting enough data to grow one page inside the transaction and checking pg_relation_size before and after the rollback. All that story about visibility map, reindexing, vacuuming indices, or imagine that in the future we have another way to satisfy the query without the indices. +CREATE TABLE tbspace_19686 (a int); Do we need to keep that ticket number here? Maybe in the commit message. That suffix impairs readability in my opinion. + * Give one of a table's indexes a fresh relfilenumber within its existing + * tablespace, copying the current index file to the new relfilenumber. This is very counterintuitive, moving to a different tablespace should not take up more space in the original tablespace. > If one is moving to a different tablespace, chances are that the current tablespace > is too full, and adding files there would possibly make it worse. It would make > sense to take up space in the target tablespace not the source. Regards, Alexandre
