Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?)

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

In response to

Browse pgsql-hackers by date

  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