Re: "could not reattach to shared memory" captured in buildfarm

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Dave Page <dpage(at)postgreSQL(dot)org>
Subject: Re: "could not reattach to shared memory" captured in buildfarm
Date: 2009-05-04 08:29:12
Message-ID: 49FEA758.80605@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> vaquita has an interesting report today:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=vaquita&dt=2009-05-01%2020:00:06
>
> Partway through the contrib tests, for absolutely no visible reason
> whatsoever, connections start to fail with
> FATAL: could not reattach to shared memory (key=364, addr=02920000): 487

Note that 487 is "invalid address", and should not have anything to do
with the issues Andrew mentioned (which were about the already-exists
error).

Somebody else mentioned, and IIRC I talked to Dave about this before,
that this could be because the address is no longer available. The
reason for this could be some kind of race condition in the backends
starting - the address is available when the postmaster starts and thus
it's used, but when a regular backend starts, the memory is used for
something else.

One proposed fix is to allocate a fairly large block of memory in the
postmaster just before we get the shared memory, and then free it right
away. The effect should be to push down the shared memory segment
further in the address space.

Comments?

//Magnus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2009-05-04 08:36:45 Re: windows shared memory error
Previous Message James Pye 2009-05-04 08:18:50 Re: Python 3.0 does not work with PL/Python