From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, 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-10-31 01:26:31 |
Message-ID: | 8400.1383182791@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-10-31 02:28:53 | Re: Something fishy happening on frogmouth |
Previous Message | Tom Lane | 2013-10-30 21:32:46 | Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs? |