Pavan Deolasee wrote:
> In this specific context, this particular case is easy to handle because
> we are only concerned about the serializable transactions started before
> CREATE INDEX commits. If PREPARE can see the new index, it
> implies that the CI transaction is committed. So the transaction
> starting after than can only see the tuple version that we have indexed.
Yes, but the non-index plan PREPARE generated will be used until the end
of the session, nut only until the end of the transaction. Imagine that
it wasn't explicitly PREPARED (where you might say this is acceptable),
but rather just a query inside a plpgsql function, maybe even called
from some app using connection pooling. This means that the non-index
using plan might get used for a quite long time, which contradics the
work Tom did on plan invalidation I think.
Maybe Tom can comment on wheter it's possible to use plan invalidation
to eventually get rid of a stale plan in this context?
greetings, Florian Pflug
