Re: Something fishy happening on frogmouth

On Wed, Oct 30, 2013 at 9:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> If it *isn't* about the main memory segment, what the hell are we doing
>>> creating random addon segments during bootstrap? None of the DSM code
>>> should even get control at this point, IMO.
>
>> Here's a short summary of what I posted back in August: at system
>> startup time, the postmaster creates one dynamic shared segment,
>> called the control segment.
>
> Well, as I've pointed out already in this thread, the postmaster does not
> execute during bootstrap, which makes me think this code is getting called
> from the wrong place. What possible reason is there to create add-on shm
> segments in bootstrap mode? I'm even dubious that we should create them
> in standalone backends, because there will be no other process to share
> them with.
>
> I'm inclined to think this initialization should be moved to the actual
> postmaster (and I mean postmaster.c) from wherever it is now. That might
> fix the not-so-random name choice in itself, but if it doesn't, then we
> could consider where to move the random-seed-initialization step to.

The initialization code is currently called form
CreateSharedMemoryAndSemaphores(), like this:

/* Initialize dynamic shared memory facilities. */
if (!IsUnderPostmaster)
dsm_postmaster_startup();

The reason I put it there is that if the postmaster does a
crash-and-restart cycle, we need create a new control segment just as
we need to create a new main shared memory segment. (We also need to
make sure all dynamic shared memory segments left over from the
previous postmaster lifetime get nuked, but that happens earlier, as
part of the shmem_exit sequence.)

There may be a good reason to move it elsewhere, but by and large I
have not had good luck deviating from the pattern laid down for the
main shared memory segment. My respect for that battle-tested code is
growing daily; every time I think I know better, I get burned.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company