Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

Поиск
Список
Период
Сортировка
От Nikolay Shaplov
Тема Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind
Дата
Msg-id 1972481.VQZ2401KyW@home
обсуждение исходный текст
Ответ на Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
В письме от 27 мая 2016 15:05:58 Вы написали:
> Nikolay Shaplov wrote:
> > Story start from the point that I found out that a.m. can not forbid
> > changing some of it's reloptions with ALTER INDEX command. That was not
> > necessary before, because all reloptions at that existed at that time can
> > be changed on fly. But now for bloom index it is unacceptable, because
> > for changing bloom's reloptions for existing index will lead to index
> > malfunction.
>
> Hmm, this sounds like a bug to me.  In BRIN, if you change the
> pages_per_range option for an existing index, the current index
> continues to work because the value used during the last index build is
> stored in the metapage.  Only when you reindex after changing the option
> the new value takes effect.
>
> I think Bloom should do likewise.

I do not think that it is the best behavior. Because if we came to this
situation, the current value of pages_per_range that index actually using is
not available for user, because he is not able to look into meta page.

In this case it would be better either forbid changing the options, so it
would be consistent, or force index rebuild, then it would be consistent too.
I would vote for first behavior as this is less work to do for me, and can be
changed later, if it is really needed for some case.

PS sorry I did not add mail list to the CC, so I send it second time...



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind