Re: Changing shared_buffers without restart - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: Changing shared_buffers without restart
Date
Msg-id CAEze2Wgf0M5S2x1j+f-haUpCGdzP_J8KVP-JYsBqdOX0-XKvqA@mail.gmail.com
Whole thread Raw
In response to Re: Changing shared_buffers without restart  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Changing shared_buffers without restart
List pgsql-hackers
On Thu, 28 Nov 2024 at 18:19, Robert Haas <robertmhaas@gmail.com> wrote:
>
> [...] It's unclear to me why
> operating systems don't offer better primitives for this sort of thing
> -- in theory there could be a system call that sets aside a pool of
> address space and then other system calls that let you allocate
> shared/unshared memory within that space or even at specific
> addresses, but actually such things don't exist.

Isn't that more a stdlib/malloc issue? AFAIK, Linux's mmap(2) syscall
allows you to request memory from the OS at arbitrary addresses - it's
just that stdlib's malloc doens't expose the 'alloc at this address'
part of that API.

Windows seems to have an equivalent API in VirtualAlloc*. Both the
Windows API and Linux's mmap have an optional address argument, which
(when not NULL) is where the allocation will be placed (some
conditions apply, based on flags and specific API used), so, assuming
we have some control on where to allocate memory, we should be able to
reserve enough memory by using these APIs.

Kind regards,

Matthias van de Meent
Neon (https://neon.tech)



pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: POC, WIP: OR-clause support for indexes
Next
From: Corey Huinker
Date:
Subject: Re: More CppAsString2() in psql's describe.c