Thread: [HACKERS] [RFC] Should "SHOW huge_pages" display the effective value "off"when the huge page is unavailable?

Hello, all

Could you give me your opinions on whether the SHOW command should display the effective value or the specified value
forhuge_pages?  During the review of "Supporting huge_pages on Windows", which is now shifted to CommitFest 2017-3,
Magnusgave me a comment that the huge_page variable should retain the value "try" when the huge page is not available
onthe machine and the server falls back to huge_page=off.  The Linux version does so.
 

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.
SHOWdisplays huge_pages as off, not try.  Otherwise, the user cannot know whether the huge page setting is effective.
 

One parameter that behaves similarly is wal_buffers.  When wal_buffers is set to -1 (default), "SHOW wal_buffers"
displaysthe actual size, not -1.  But I didn't find any other parameters like this.
 

Regards
Takayuki Tsunakawa

On Mon, Feb 6, 2017 at 4:01 PM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> Hello, all
>
> Could you give me your opinions on whether the SHOW command should display the effective value or the specified value
forhuge_pages?  During the review of "Supporting huge_pages on Windows", which is now shifted to CommitFest 2017-3,
Magnusgave me a comment that the huge_page variable should retain the value "try" when the huge page is not available
onthe machine and the server falls back to huge_page=off.  The Linux version does so. 
>
> 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.

Regards,

--
Fujii Masao

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 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.
        regards, tom lane

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

Fujii Masao <masao.fujii@gmail.com> writes:
> On Tue, Feb 7, 2017 at 12:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

Well, then you wouldn't know whether the true setting was "try" or not,
which is important information because of the crash/restart possibility.
If we went this direction, I think the SHOW output would have to read
something like "try (off)" or "try (on)", which is why I was concerned
about it not being acceptable SET input.

>> 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

But it's moot anyway if we're agreed that a separate function is better.
        regards, tom lane