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

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?)
Дата
Msg-id 45FE51D9.1020700@enterprisedb.com
обсуждение исходный текст
Ответ на Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?)  ("Simon Riggs" <simon@2ndquadrant.com>)
Ответы Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?)  ("Simon Riggs" <simon@2ndquadrant.com>)
Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?)  ("Merlin Moncure" <mmoncure@gmail.com>)
Список pgsql-hackers
Simon Riggs wrote:>>> We *must* make CREATE INDEX CONCURRENTLY work with HOT. The good news is> I think we can without
significantdifficulty.>
 

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.

Am I missing something in your design that stops this from
happening ?

Thanks,
Pavan


-- 


EnterpriseDB        http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Buildfarm feature request: some way to track/classify failures
Следующее
От: "Pavan Deolasee"
Дата:
Сообщение: CREATE INDEX and HOT - revised design