2020年1月29日(水) 11:06 Thomas Munro <thomas.mu...@gmail.com>: > > On Wed, Jan 29, 2020 at 2:49 PM Kohei KaiGai <kai...@heterodb.com> wrote: > > 2020年1月29日(水) 4:27 Thomas Munro <thomas.mu...@gmail.com>: > > > On Tue, Jan 28, 2020 at 2:55 PM Kohei KaiGai <kai...@heterodb.com> wrote: > > > FWIW the code in https://commitfest.postgresql.org/26/2325/ ran into > > > exactly the same problem while making nearly exactly the same kind of > > > thing (namely, a MemoryContext backed by space in the main shm area, > > > in this case reusing the dsa.c allocator). > > > > > Thanks, I had looked at "Shared Memory Context" title on pgsql-hackers a few > > months ago, however, missed the thread right now. > > > > The main point of the differences from this approach is portability of > > pointers > > to shared memory chunks. (If I understand correctly) > > PG-Strom preserves logical address space, but no physical pages, on startup > > time, then maps shared memory segment on the fixed address on demand. > > So, pointers are portable to all the backend processes, thus, suitable to > > build > > tree structure on shared memory also. > > Very interesting. PostgreSQL's DSM segments could potentially have > been implemented that way (whereas today they are not mapped with > MAP_FIXED), but I suppose people were worried about portability > problems and ASLR. The Windows port struggles with that stuff. > Yes. I'm not certain whether Windows can support equivalen behavior to mmap(..., PROT_NONE) and SIGSEGV/SIGBUS handling. It is also a reason why PG-Strom (that is only for Linux) wants to have own shared memory management logic, at least, right now.
Thanks, -- HeteroDB, Inc / The PG-Strom Project KaiGai Kohei <kai...@heterodb.com>
