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 <tomas@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
