Pavan Deolasee wrote:
> There is a slight hole in that SERIALIZABLE transactions won't be able
>> to use any indexes they build during their transaction, since they may
>> need to be able to see prior data, but I don't think anybody is going to
>> complain about that restriction. Anyone?
>
> Oh, I did not see that. If there are no HOT-chains in the table, we can
> set the xid to InvalidTransactionId so that the index is usable immediately
> after it is created in the current transaction, as well as those
> transactions
> which were started before CREATE INDEX. We can possibly further
> improve it by checking if there are no HOT-chains except those created
> by this transaction and set xid to InvalidTransactionId. IMO with that we
> shall address most of the use cases. There are few which might
> still get impacted, but even for them there won't be any correctness
> problem.
Why exactly can't a SERIALIZABLE transaction use the index it created
itself? If you add a pointer to the root of all HOT update chains where
either the HEAD is alive, or some tuple is visible to the transaction
creating the index, shouldn't this be sufficient for using the index
in the creating transaction?
greetings, Florian Pflug