From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Subject: | Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?) |
Date: | 2007-03-19 17:14:45 |
Message-ID: | b42b73150703191014u8b838a8g9be1c269e4ee9dec@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/19/07, Pavan Deolasee <pavan(dot)deolasee(at)enterprisedb(dot)com> wrote:
> Yeah, I think CREATE INDEX CONCURRENTLY is much easier to solve. Though
> I am not completely convinced that we can do that without much changes
> to CREATE INDEX CONCURRENTLY logic. For example, I believe we still
> need to lock out HOT-updates before we start CREATE INDEX CONCURRENTLY.
> Otherwise we might end up creating two paths to the same tuple in
> the new index.
>
> Say, we have a table with two columns (int a, int b). We have an
> index on 'a' and building another index on 'b'. We got a tuple
> (10, 20) in the heap. In the first phase of CREATE INDEX CONCURRENTLY,
> this tuple would be indexed. If the tuple is HOT-updated to (10, 30)
> before the first phase ends, the updated tuple would again get
> indexed in the second phase. This would lead to two paths to the
> latest visible tuple from the new index.
just a thought...can you disable HOT on the fly? why not disable hot
updates completely during these types of operations?.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-03-19 17:29:13 | Re: modifying the tbale function |
Previous Message | Tom Lane | 2007-03-19 17:14:03 | Re: Buildfarm feature request: some way to track/classify failures |