Re: CREATE INDEX and HOT - revised design - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CREATE INDEX and HOT - revised design
Date
Msg-id 22876.1175183105@sss.pgh.pa.us
Whole thread Raw
In response to Re: CREATE INDEX and HOT - revised design  ("Florian G. Pflug" <fgp@phlo.org>)
Responses Re: CREATE INDEX and HOT - revised design  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Re: CREATE INDEX and HOT - revised design  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
"Florian G. Pflug" <fgp@phlo.org> writes:
> Pavan Deolasee wrote:
>> Frankly I don't know this works, but are you sure that the plan will
>> be used until the end of the session ? Even if thats the case, it can
>> happen even today if we create a new index, but the existing sessions
>> will use the stale plan (assuming what you said is true)

> I've checked that:

Evidently you weren't testing on HEAD.

> The open question is how CVS HEAD with plan invalidation behaves.
> If it replans after the index-creating transaction commits, then
> basing index validity on a snapshot will break this, because upon
> replay they index might not be useable, but later on it may very
> well be (but that plan invalidation machinery won't realize that)

It will replan at the first use of the plan after seeing the relcache
inval sent by commit of the index-creating transaction.  If you have
two separate transactions to create an index and then mark it valid
later, everything's fine because there are two inval events.
However, if you design something where an index becomes usable due
to the passage of time rather than an explicit mark-valid step,
there's gonna be a problem.  I'd suggest trying to stick to the
way CREATE INDEX CONCURRENTLY does it...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: ECPG regression tests expected files
Next
From: Tom Lane
Date:
Subject: Re: Modifying TOAST thresholds