Hi, On 2025-04-09 00:47:59 +0200, Tomas Vondra wrote: > On 4/8/25 16:59, Andres Freund wrote: > > 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. > > > > Makes sense, done in the attached patch. > > > 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. > > > > True. It's true it's not really "NUMA page", but page size for the shmem > segment. So renamed to pg_get_shmem_pagesize() and moved to shmem.c, > same as pg_numa_available().
Cool. > The rest of pg_numa.c is moved to src/backend/port Why move the remainder? It shouldn't have any dependency on postgres.h afterwards? And I think it's not backend-specific. Greetings, Andres Freund
