On Fri, Jun 17, 2016 at 10:18 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jun 17, 2016 at 11:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> But I'm a bit confused about where it gets the bytes it wants to
> manage. There's no call to dsm_create() or ShmemAlloc() anywhere in
> the code, at least not that I could find quickly. The only way to get
> shar_base set to a non-NULL value seems to be to call SharAttach(),
> and if there's no SharCreate() where would we get that non-NULL value?
>
You are right, I just have to tidy up the initialisation code before
publishing it.
> I expect that to be useful for parallel query and anything else where
> processes need to share variable-size data. However, that's different
> from this because ours can grown to arbitrary size and shrink again by
> allocating and freeing with DSM segments. We also do everything with
> relative pointers since DSM segments can be mapped at different
> addresses in different processes, whereas this would only work with
> memory carved out of the main shared memory segment (or some new DSM
> facility that guaranteed identical placement in every address space).
>
I believe it would be perfectly okay to allocate huge amount of address
space with mmap on startup. If the pages are not touched, the OS VM
subsystem will not commit them.
> I've been a bit reluctant to put it out there
> until we have a tangible application of the allocator working, for
> fear people will say "that's not good for anything!". I'm confident
> it's good for lots of things, but other people have been known not to
> share my confidence.
>
This is what I've been told by Postgres Pro folks too. But I felt that this
thing deserves to be shown to the community sooner rather than latter.
Regards,
Aleksey