Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Tom Lane wrote:
>>> I do not think you can assume that the plan won't be used later with
>>> some older snapshot.
>
>> So maybe we'd need to use the SerializableSnapshot created at the start
>> of each transaction for this check, and not the ActiveSnapshot? Could
>> that work?
>
> 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.
Pavan suggested storing the IndexSnapshot in the cached plan, and to
compare it to the IndexSnapshot when the query is executed.
If those two snapshots differ, the query would be replanned.
My idea was to store a list of xid's together with the cached plan that
are assumed to be uncommitted accoring to the IndexSnapshot. The query
is replanned if upon execution the IndexSnapshot assumes that one of
these xid's is committed.
Those two ideas seem to be mostly equivalent, mine seems to be a bit
more fine-grained, but at the cost of more work upon each query execution.
greetings, Florian Pflug