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

From Pavan Deolasee
Subject Re: CREATE INDEX and HOT - revised design
Date
Msg-id 2e78013d0703282030l514eeb38j77969ca54d1aced8@mail.gmail.com
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  ("Florian G. Pflug" <fgp@phlo.org>)
List pgsql-hackers


On 3/29/07, Florian G. Pflug <fgp@phlo.org> wrote:
Pavan Deolasee wrote:

> Tom, please correct me if I am wrong. But ISTM that this idea might
> work in this context. In get_relation_info(), we would check if "xcreate"
> xid stored in pg_index for the index under consideration is seen
> committed with respect to the snapshot at that point of time.
> Even if the snapshot changes later and index becomes valid, we
> might not replan and hence not use index. But that doesn't seem
> like a big problem to me.

That problem are usecases like
PREPARE my_plan .... ;
BEGIN;
EXECUTE my_plan .... ;
COMMIT ;


Oh, I see.
 

Is that "PREPARE" even run inside a transaction? Even if it is, it
probably won't have created a snapshot...


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.
 

But I don't know if this is the only case or there are more cases to
consider :-(


Thanks,
Pavan

--

EnterpriseDB     http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Carlo Florendo
Date:
Subject: Re: Patch queue concern
Next
From: Tom Lane
Date:
Subject: Re: Patch queue concern