Pavan Deolasee wrote:
> On 3/30/07, Florian G. Pflug <fgp@phlo.org> wrote:
>>
>> 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.
>>
>>
> Actually, if we are using Serializable Snapshot then there is no chance
> to replan the query before the transaction completes and the next
> transaction to start in the session must see the index and hence
> we must replan. So it would be enough just to associate a transaction
> id with the cached plan. If this xid is set and our transaction id is
> different than that, we replan.
I believe this is true for the CREATE INDEX scenario. However, comparing
either the snapshot or the result of xid checks seems like it might
be useful for other things beside CREATE INDEX. I'm specifically
thinking about TRUNCATE here - the create index + HOT problems sound
quite similar to the problems a non-exclusive-locking TRUNCATE would face.
greetings, Florian Pflug