From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Changing shared_buffers without restart |
Date: | 2024-11-28 18:57:15 |
Message-ID: | 23998.1732820235@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> writes:
> On Thu, 28 Nov 2024 at 18:19, Robert Haas <robertmhaas(at)gmail(dot)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.
I think what Robert is concerned about is that there is exactly 0
guarantee that that will succeed, because you have no control over
system-driven allocations of address space (for example, loading
of extensions or JIT code). In fact, given things like ASLR, there
is pressure on the kernel crew to make that *less* predictable not
more so. So even if we devise a method that seems to work reliably
today, we could have little faith that it would work with next year's
kernels.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alena Rybakina | 2024-11-28 19:03:36 | Re: POC, WIP: OR-clause support for indexes |
Previous Message | Dmitry Dolgov | 2024-11-28 18:45:49 | Re: Changing shared_buffers without restart |