Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?)
От | Merlin Moncure |
---|---|
Тема | Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?) |
Дата | |
Msg-id | b42b73150703191014u8b838a8g9be1c269e4ee9dec@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?) ("Pavan Deolasee" <pavan.deolasee@enterprisedb.com>) |
Список | pgsql-hackers |
On 3/19/07, Pavan Deolasee <pavan.deolasee@enterprisedb.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
В списке pgsql-hackers по дате отправления: