Re: FATAL: could not reattach to shared memory (Win32)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Shelby Cain <alyandon(at)yahoo(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Terry Yapt <yapt(at)technovell(dot)com>, Trevor Talbot <quension(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: FATAL: could not reattach to shared memory (Win32)
Date: 2007-08-24 19:47:30
Message-ID: 4696.1187984850@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Shelby Cain <alyandon(at)yahoo(dot)com> writes:
> Assuming this is an issue with shared libraries, I think it would have more=
> to do with the way Windows resolves address conflicts on process startup t=
> han anything caused by explicit calls to LoadLibrary(). Looking at postgre=
> s.exe with the dependency viewer from Visual Studio 6, I see that the follo=
> wing shared library dependencies embedded in the executable image that havi=
> ng conflicting base addresses. If I'm not mistaken, Windows will automatic=
> ally relocate these libraries prior to actual code execution so there would=
> be no opportunity for that particular instance of postgres.exe to map the =
> shared memory if the address space is already in use by a relocated dll.

But the shmem was originally allocated in the postmaster process, which
is the identical executable with the identical set of linked-in DLLs.
So it's really unclear why the child processes would be unable to
reattach at the same address.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-08-24 19:59:53 Re: PG Seg Faults Performing a Query
Previous Message Bill Thoen 2007-08-24 19:43:11 Re: PG Seg Faults Performing a Query