Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update
Дата
Msg-id 19546.1353965979@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Problem Observed in behavior of Create Index Concurrently and Hot Update  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2012-10-31 11:41:37 +0530, Amit Kapila wrote:
>> There seems to be a problem in behavior of Create Index Concurrently and Hot
>> Update in HEAD code .

> At pgcon.it I had a chance to discuss with Simon how to fix this
> bug. Please check the attached patches - and their commit messages - for
> the fix and some regression tests.

I looked at this a bit.  I am very unhappy with the proposed kluge to
open indexes NoLock in some places.  Even if that's safe today, which
I don't believe in the least, any future change in this area could break
it.

I'm a bit inclined to think that DROP INDEX CONCURRENTLY should have an
additional step that somehow marks the pg_index row in a new way that
makes RelationGetIndexList ignore it, and then wait out existing
transactions before taking the final step of dropping the index.  The
Right Way to do this would likely have been to add another bool column,
but we don't have that option anymore in 9.2.  Maybe we could abuse
indcheckxmin somehow, ie use a state that can't otherwise occur (in
combination with the values of indisvalid/indisready) to denote an index
being dropped.
        regards, tom lane



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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Materialized views WIP patch
Следующее
От: "Karl O. Pinc"
Дата:
Сообщение: Re: Suggestion for --truncate-tables to pg_restore