Re: Something fishy happening on frogmouth

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Something fishy happening on frogmouth
Date: 2013-11-04 11:13:27
Message-ID: 52778157.9050907@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-11-04 11:19:12 Re: Something fishy happening on frogmouth
Previous Message Michael Paquier 2013-11-04 10:57:43 Re: Removal of archive in wal_level