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

From: Nikolay Shaplov <n(dot)shaplov(at)postgrespro(dot)ru>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind
Date: 2016-05-27 19:24:50
Message-ID: 1972481.VQZ2401KyW@home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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...

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-05-27 19:30:46 Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind
Previous Message Alvaro Herrera 2016-05-27 19:05:58 Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind