Re: "could not reattach to shared memory" captured in buildfarm - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: "could not reattach to shared memory" captured in buildfarm
Date
Msg-id 49FEF8F7.9040809@hagander.net
Whole thread Raw
In response to Re: "could not reattach to shared memory" captured in buildfarm  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "could not reattach to shared memory" captured in buildfarm  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> 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.
> 
> How is it no longer available, when the new backend is a brand new
> process?  The "race condition" bit seems even sillier --- if there
> are multiple backends starting, they're each an independent process.

Because some other DLL that was loaded on process startup allocated
memory differently - in a different order, different size because or
something, or something like that.

I didn't mean race condition between backends. I meant against a
potential other thread started by a loaded DLL for initialization.
(Again, things like antivirus are known to do this, and we do see these
issues more often if AV is present for example)

//Magnus



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: windows shared memory error
Next
From: Andres Freund
Date:
Subject: conditional dropping of columns/constraints