Hi, On 2025-04-08 09:35:37 -0400, Andres Freund wrote: > On April 8, 2025 9:21:57 AM EDT, Tomas Vondra <to...@vondra.me> wrote: > >On 4/8/25 15:06, Andres Freund wrote: > >> On 2025-04-08 17:44:19 +0500, Kirill Reshke wrote: > >> I think it's not right that something in src/port defines an SQL callable > >> function. The set of headers for that pull in a lot of things. > >> > >> Since the file relies on things like GUCs, I suspect this should be in > >> src/backend/port or such instead. > >> > > > >Yeah, I think you're right, src/backend/port seems like a better place > >for this. I'll look into moving that in the evening. > > On a second look I wonder if just the SQL function and perhaps the page size > function should be moved. There are FE programs that could potentially > benefit from num a awareness (e.g. pgbench).
I would move pg_numa_available() to something like src/backend/storage/ipc/shmem.c. I wonder if pg_numa_get_pagesize() should loose the _numa_ in the name, it's not actually directly NUMA related? If it were pg_get_pagesize() it'd fit in with shmem.c or such. Or we could just make it work in FE code by making this part Assert(IsUnderPostmaster); Assert(huge_pages_status != HUGE_PAGES_UNKNOWN); if (huge_pages_status == HUGE_PAGES_ON) GetHugePageSize(&os_page_size, NULL); #ifndef FRONTEND - we don't currently support using huge pages in FE programs after all. But querying the page size might still be useful. Regardless of all of that, I don't think the include of fmgr.h in pg_numa.h is needed? Greetings, Andres Freund