On Tue, Feb 7, 2017 at 12:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> On Mon, Feb 6, 2017 at 4:01 PM, Tsunakawa, Takayuki
>> <tsunakawa.takay@jp.fujitsu.com> wrote:
>>> I don't have a strong opinion on that, but I think a bit that it would be better to reflect the effective setting,
i.e.SHOW displays huge_pages as off, not try.
>
>> Not sure if this is best way to do that, but I agree that it's helpful if
>> we can see whether the server actually uses huge page or not in
>> huge_page=try case.
>
> If the proposal is to actually change the stored value of huge_pages,
> I would say "absolutely not". Suppose that you change "try" to "on",
> and there's a backend crash and restart so that the postmaster needs
> to reallocate shared memory, and this time it's unable to obtain
> huge pages for some reason. Taking the database down would be entirely
> the wrong thing. Also, how would you handle postgresql.conf reload
> situations?
>
> If the proposal is to have SHOW report something other than the setting
> of the variable, that's not a great plan either. It's generally important
> that the output of SHOW be something that's acceptable to SET, as not
> having that equivalence will break assorted client-side code.
I was thinking that Tunakawa-san's proposal is this, i.e., use GUC show-hook
to show "off" if the server fails to use huge-page and "on" otherwise.
> I think this desire would be better addressed by some kind of specialized
> inquiry function, which would also be able to return more information than
> just a naked "on/off" bit. People might for instance wish to know what
> hugepage size is in use.
+1
Regards,
--
Fujii Masao