At Fri, 3 Sep 2021 17:46:05 +0000, "Bossart, Nathan" <bossa...@amazon.com> wrote in > On 9/2/21, 10:12 PM, "Kyotaro Horiguchi" <horikyota....@gmail.com> wrote: > > By the way I noticed that postgres -C huge_page_size shows 0, which I > > think should have the number used for the calculation if we show > > huge_page_required. > > I would agree with this if huge_page_size was a runtime-computed GUC, > but since it's intended for users to explicitly request the huge page > size, it might be slightly confusing. Perhaps another option would be > to create a new GUC for this. Or maybe it's enough to note that the > value will be changed from 0 at runtime if huge pages are supported. > In any case, it might be best to handle this separately.
(Sorry, I was confused, but) yeah, agreed. > > I noticed that postgres -C shared_memory_size showed 137 (= 144703488) > > whereas the error message above showed 148897792 bytes (142MB). So it > > seems that something is forgotten while calculating > > shared_memory_size. As the consequence, launching postgres setting > > huge_pages_required (69 pages) as vm.nr_hugepages ended up in the > > "could not map anonymous shared memory" error. > > Hm. I'm not seeing this with the v5 patch set, so maybe I > inadvertently fixed it already. Can you check this again with v5? Thanks! I confirmed that the numbers match with v5. regards. -- Kyotaro Horiguchi NTT Open Source Software Center