From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>, Dmitry Dolgov <9erthalion6@gmail.com>,
        pgsql-hackers@postgresql.org
Subject: Re: Changing shared_buffers without restart
In-reply-to: <CAEze2WiMkmXUWg10y+_oGhJzXirZbYHB5bw0=VWte+YHwSBa=A@mail.gmail.com>
References: <cnthxg2eekacrejyeonuhiaezc7vd7o2uowlsbenxqfkjwgvwj@qgzu6eoqrglb> <CA+TgmoZFfn0E+EkUAjnv_QM_00eUJPkgCJKzm3n1G4itJKMSsA@mail.gmail.com> <pw5phxoc34xh4o5mtv7x4ujgf3jmdsiihbi5n5d5ucy64ksjow@7i6gkeeqrp6w> <CA+TgmobX48--shtSdCL7L2zqC7XASQkVcyDGbmP1K82m3H=q+Q@mail.gmail.com> <eagfj5dqkmgko36hihru27aynghp62sigu7zyvuvmou4zf2t4y@2sdesnfor7dd> <CA+TgmoZSGtWQRrzkTrK395zQPnZtmXSfjDzo+GxCgf3Mwe_M3A@mail.gmail.com> <scor5gscd42d4nwszuwvtwss6e22fg3dnvxmqwrcsdkpyyigny@efjlkj6ccv7u> <CA+TgmoacEMv7LM-44ZfsCR4T033J+h8qmkpKB75gnhNR3kdTkg@mail.gmail.com> <CAEze2Wgf0M5S2x1j+f-haUpCGdzP_J8KVP-JYsBqdOX0-XKvqA@mail.gmail.com> <23998.1732820235@sss.pgh.pa.us> <CAEze2WiMkmXUWg10y+_oGhJzXirZbYHB5bw0=VWte+YHwSBa=A@mail.gmail.com>
Comments: In-reply-to Matthias van de Meent <boekewurm+postgres@gmail.com>
	message dated "Fri, 29 Nov 2024 01:56:30 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <397217.1732844567.1@sss.pgh.pa.us>
Date: Thu, 28 Nov 2024 20:42:47 -0500
Message-ID: <397218.1732844567@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/397218.1732844567%40sss.pgh.pa.us>
Precedence: bulk

Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> I mean, we can do the following to get a nice contiguous empty address
> space no other mmap(NULL)s will get put into:

>     /* reserve size bytes of memory */
>     base = mmap(NULL, size, PROT_NONE, ...flags, ...);
>     /* use the first small_size bytes of that reservation */
>     allocated_in_reserved = mmap(base, small_size, PROT_READ |
> PROT_WRITE, MAP_FIXED, ...);

> With the PROT_NONE protection option the OS doesn't actually allocate
> any backing memory, but guarantees no other mmap(NULL, ...) will get
> placed in that area such that it overlaps with that allocation until
> the area is munmap-ed, thus allowing us to reserve a chunk of address
> space without actually using (much) memory.

Well, that's all great if it works portably.  But I don't see one word
in either POSIX or the Linux mmap(2) man page that promises those
semantics for PROT_NONE.  I also wonder how well a giant chunk of
"unbacked" address space will interoperate with the OOM killer,
top(1)'s display of used memory, and other things that have caused us
headaches with large shared-memory arenas.

Maybe those issues are all in the past and this'll work great.
I'm not holding my breath though.

			regards, tom lane