"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> AFAICS, the whole indcreatexid and validForTxn business is a waste of
> code. By the time CREATE INDEX CONCURRENTLY is ready to set indisvalid,
> surely any transactions that could see the broken HOT chains are gone.
> There might have been some reason for this contraption before we had
> plan invalidation, but what use is it now?
It sounds like you're missing one of the big problems HOT ran into. When you
create a new index your new index could include columns which were previously
not covered in any index. So there could be pre-existing HOT chains which
would no longer be eligible for HOT treatment. The README called such chains
"broken HOT chains" and has some more information about them.
Nobody who can see any old tuples in such chains can risk using your new index
since the chain will be indexed under the "wrong" key. *New* transactions can
use the index however since they'll only see the head of the chain which is
the key the chain is indexed under. It's the old transactions which can see
the old key values which aren't included in the index.
Or do you see some other reason that plan invalidation can solve this problem?
We looked for and tried a lot of different approaches to solve this problem.
This was the lowest impact solution and the only one that was convincingly
correct (imho).
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com