On 04.11.2013 11:55, Andres Freund wrote:
On 2013-11-04 10:27:47 +0200, Heikki Linnakangas wrote:
Hmm, here's another idea:
Postmaster creates the POSIX shared memory object at startup, by calling
shm_open(), and immediately calls shm_unlink on it. That way, once all the
processes have exited, the object will be removed automatically. Child
processes inherit the file descriptor at fork(), and don't need to call
shm_open, just mmap().
Uh. Won't that completely and utterly remove the point of dsm which is
that you can create segments *after* startup? We surely don't want to
start overallocating enough shmem so we don't ever dynamically need to
allocate segments.
You don't need to allocate the shared memory beforehand, only create the
file descriptor. Note that the size of the segment is specified in the
shm_open() call, but the mmap() that comes later.
If we need a large amount of small segments, so that it's not feasible
to shm_open() them all at postmaster startup, you could shm_open() just
one segment, and carve out smaller segments from it by mmap()ing at
different offsets.
Also, I don't think it's portable across platforms to access segments
that already have been unlinked.
See
http://pubs.opengroup.org/onlinepubs/009695299/functions/shm_unlink.html: "If
one or more references to the shared memory object exist when the object
is unlinked, the name shall be removed before shm_unlink() returns, but
the removal of the memory object contents shall be postponed until all
open and map references to the shared memory object have been removed."
That doesn't explicitly say that a new shm_open() on the file descriptor
must still work after shm_unlink, but I would be surprised if there is a
platform where it doesn't.
I think this is looking for a solution without an actually relevant
problem disregarding the actual problem space.
I agree. What are these dynamic shared memory segments supposed to be
used for?
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
