Thanks again Thomas,
> Oh, so maybe we need a configure test for them? And if you don't have
> it, a runtime error if you try to set the page size to something other
> than 0 (like we do for effective_io_concurrency if you don't have a
> posix_fadvise() function).
Ahh, yes, that sounds reasonable. Did some fiddling with the configure
script to add a check, and think I got it right (but not 100% sure
tho.). Added new v3 patch.
> If you set it to an unsupported size, that seems reasonable to me. If
> you set it to an unsupported size and have huge_pages=try, do we fall
> back to using no huge pages?
Yes, the "fallback" with huge_pages=try is the same for both
huge_page_size=0 and huge_page_size=nMB, and is the same as without
this patch.
> For what it's worth, here's what I know about this on other operating systems:
Thanks for all the background info!
> 1. AIX can do huge pages, but only if you use System V shared memory
> (not for mmap() anonymous shared). In
> https://commitfest.postgresql.org/25/1960/ we got as far as adding
> support for shared_memory_type=sysv, but to go further we'll need
> someone willing to hack on the patch on an AIX system, preferably with
> root access so they can grant the postgres user wired memory
> privileges (or whatever they call that over there). But at a glance,
> they don't have a way to ask for a specific page size, just "large".
Interesting. I might get access to some AIX systems at university this fall,
so maybe I will get some time to dive into the patch.
Odin