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
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 |