Re: Changing shared_buffers without restart
От | Matthias van de Meent |
---|---|
Тема | Re: Changing shared_buffers without restart |
Дата | |
Msg-id | CAEze2Wgf0M5S2x1j+f-haUpCGdzP_J8KVP-JYsBqdOX0-XKvqA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Changing shared_buffers without restart (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Changing shared_buffers without restart
|
Список | 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 по дате отправления: