That might work, but it doesn't seem to address the core objection: there's no mechanism to cause the query to be replanned once the snapshot is new enough, because no relcache inval will happen. So most likely existing backends will keep using old plans that don't consider the index.
Can't we store the snapshot (or may be the transaction id) which was used to plan the query in CachedPlanSource if and only if at least one index was seen unusable ? In RevalidateCachedPlan() we then check if the snapshot has changed and replan the query in that case.
That would make the index usable in the subsequent transactions in the same session, though we may not be able to use the index in the same transaction, even if its running in read-commited mode. Would that be acceptable ?
