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
Дата
Msg-id 20160527190558.GA703687@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind  (Nikolay Shaplov <n.shaplov@postgrespro.ru>)
Ответы Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind  (Nikolay Shaplov <n.shaplov@postgrespro.ru>)
Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Hard to maintain duplication in contain_volatile_functions_not_nextval_walker
Следующее
От: Nikolay Shaplov
Дата:
Сообщение: Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind