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

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update
Дата
Msg-id CABOikdObu2+X1-Cgmg3Ny-hwxeGGvyLjLtEkYMiXUL2O2KALKA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers



On Tue, Nov 27, 2012 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavan Deolasee <pavan.deolasee@gmail.com> writes:
> On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Either state of indcheckxmin is valid with all three of these
>> combinations, so the specific kluge I was contemplating above doesn't
>> work.  But there is no valid reason for an index to be in this state:
>> indisvalid = true, indisready = false

> Yeah, this looks much better, given our inability to add a new catalog
> column in 9.2. Can we cheat a little though and use a value other than 0
> and 1 for indisvalid or indisready to tell the server to interpret it
> differently ?

No, not unless you'd like "select * from pg_index" to misbehave.
Personally, I like being able to look at catalogs.


Hmm.. I thought so. Thanks.

If we add a new column to the catalog for HEAD, I think it will be a good idea to add an "indflags" kind of column which can store a bitmap of flags. We probably don't get into this kind of situation often, but if we do, then we can more flexibility without impacting rebuilding the catalogs. My two cents.

Thanks,
Pavan

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: Re: Problem Observed in behavior of Create Index Concurrently and Hot Update