On Tue, Feb 7, 2017 at 12:36 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Fujii Masao <masao.fu...@gmail.com> writes: >> On Mon, Feb 6, 2017 at 4:01 PM, Tsunakawa, Takayuki >> <tsunakawa.ta...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
