Re: pgsql: Get rid of the dynamic shared memory state file.

On 2014-04-08 16:17:46 -0400, Robert Haas wrote:
> On Tue, Apr 8, 2014 at 4:14 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-04-08 15:45:39 +0000, Robert Haas wrote:
> >> Get rid of the dynamic shared memory state file.
> >>
> >> Instead of storing the ID of the dynamic shared memory control
> >> segment in a file within the data directory, store it in the main
> >> control segment.  This avoids a number of nasty corner cases,
> >> most seriously that doing an online backup and then using it on
> >> the same machine (e.g. to fire up a standby) would result in the
> >> standby clobbering all of the master's dynamic shared memory
> >> segments.
> >>
> >> Per complaints from Heikki Linnakangas, Fujii Masao, and Tom
> >> Lane.
> >
> > Looks like it's not working for windows yet:
> > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2014-04-08%2016%3A31%3A18
> > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=baiji&dt=2014-04-08%2017%3A00%3A01
> >
> > There's also the to_reg* commit in the ones tested by those runs, but it
> > sounds unlikely that those would trigger during initdb.
>
> Crap.  I did test that it worked with EXEC_BACKEND, but I don't have a
> Windows environment set up.  I can try to eyeball the code and see
> what might be wrong with it, but...

Not a windows guy either, but I just noticed that
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=narwhal&dt=2014-04-08%2016%3A00%3A03&stg=check
has an additional log entry, the others don't:
LOG:  dynamic shared memory control segment is corrupt

since that's apparently the first crash on narwahl related to this, it
might be a hint where things are going wrong.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services