Thread: postgres crashes - could not reattach to shared memory
Hi
Postgres crashes with -
PG "FATAL: could not reattach to shared memory (key=5432001, addr=02100000): Invalid argument.
The version is 8.2.4, the platform is win32
Does someone know the reason/workaround ?
Thanks,
Yuval Sofer
BMC Software
CTM&D Business Unit
DBA Team
972-52-4286-282
On Sun, May 2, 2010 at 5:27 PM, Sofer, Yuval <Yuval_Sofer@bmc.com> wrote:
PG "FATAL: could not reattach to shared memory (key=5432001, addr=02100000): Invalid argument.
In my previous experiences with PostgreSQL on Windows I have seen such similar type of problems when Anti-virus software was running on the system as well. If you have such installed can you try removing it and then see how it goes?
--
Shoaib Mir
http://shoaibmir.wordpress.com/
On 02/05/10 12:57 PM, Sofer, Yuval wrote: <blockquote cite="mid:2C0926ABD16BB641A8E2F11A5492004227832AFF88@PHXCCRPRD01.adprod.bmc.com"type="cite"><style> <!--/* Font Definitions */@font-face{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face{font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 2 4;}/* Style Definitions */p.MsoNormal, li.MsoNormal, div.MsoNormal{margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink{mso-style-priority:99;color:blue;text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed{mso-style-priority:99;color:purple;text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText{mso-style-priority:99;mso-style-link:"Plain Text Char";margin:0in;margin-bottom:.0001pt;font-size:10.5pt;font-family:Consolas;} span.EmailStyle17{mso-style-type:personal-compose;font-family:"Calibri","sans-serif";color:windowtext;} span.PlainTextChar{mso-style-name:"Plain Text Char";mso-style-priority:99;mso-style-link:"Plain Text";font-family:Consolas;} .MsoChpDefault{mso-style-type:export-only;} @page Section1{size:8.5in 11.0in;margin:1.0in 1.25in 1.0in 1.25in;} div.Section1{page:Section1;} --> </style><div class="Section1"><br /><p class="MsoPlainText">PG "FATAL: could not reattach to shared memory (key=5432001,addr=02100000): Invalid argument.<p class="MsoPlainText"> <br /></div></blockquote><font face="Courier New,Courier, monospace">On windows this kind of issue, generally happens due to Firewall/Antivirus Software.<br /><br />Please try with disabling the firewall/antivirus software and restart the PostgreSQL.<br /><br /> Following is a thread,which has good discussion on it:<br /><a class="moz-txt-link-freetext" href="http://www.mail-archive.com/pgsql-general@postgresql.org/msg132613.html">http://www.mail-archive.com/pgsql-general@postgresql.org/msg132613.html</a><br /><br/></font><br /> -- <br /><pre class="moz-signature" cols="72">Thanks & Regards, Vibhor Kumar. </pre>
On Sun, May 2, 2010 at 8:27 AM, Sofer, Yuval <Yuval_Sofer@bmc.com> wrote: > Hi > > > > Postgres crashes with - > > > > PG "FATAL: could not reattach to shared memory (key=5432001, > addr=02100000): Invalid argument. > > The version is 8.2.4, the platform is win32 > > Does someone know the reason/workaround ? This was fixed in 8.3.8 and 8.4.1. I'm not entirely sure why it didn't get backpatched to 8.2 - it was mentioned in the discussion about the patch, but I don't see any reason for not back patching it stated. http://archives.postgresql.org/pgsql-hackers/2009-07/thrd5.php#00782 Even if it were fixed, you would need a much newer build than 8.2.4. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Sofer, Yuval wrote on 02.05.2010 09:27: > Hi > > Postgres crashes with - > > PG "FATAL: could not reattach to shared memory (key=5432001, > addr=02100000): Invalid argument. > > The version is 8.2.4, the platform is win32 > > Does someone know the reason/workaround ? > I think this is supposed to be fixed with 8.4 Regards Thomas
Dave Page <dpage@pgadmin.org> writes: > On Sun, May 2, 2010 at 8:27 AM, Sofer, Yuval <Yuval_Sofer@bmc.com> wrote: >> PG "FATAL:� could not reattach to shared memory (key=5432001, >> addr=02100000): Invalid argument. >> >> The version is 8.2.4, the platform is win32 > This was fixed in 8.3.8 and 8.4.1. I'm not entirely sure why it didn't > get backpatched to 8.2 - it was mentioned in the discussion about the > patch, but I don't see any reason for not back patching it stated. > http://archives.postgresql.org/pgsql-hackers/2009-07/thrd5.php#00782 The patch that was being worked on at the time wouldn't have come close to applying to 8.2, because the win32 shmem code got rearranged very substantially for 8.3. However, AIUI it's the same underlying technology, so in principle it could be fixed the same way. If we take seriously the proposition that we're still supporting 8.2 on Windows, we probably ought to do something about that. If we don't, we need to officially deprecate that version. regards, tom lane
On 5/2/10, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dave Page <dpage@pgadmin.org> writes: >> On Sun, May 2, 2010 at 8:27 AM, Sofer, Yuval <Yuval_Sofer@bmc.com> wrote: >>> PG "FATAL: could not reattach to shared memory (key=5432001, >>> addr=02100000): Invalid argument. >>> >>> The version is 8.2.4, the platform is win32 > >> This was fixed in 8.3.8 and 8.4.1. I'm not entirely sure why it didn't >> get backpatched to 8.2 - it was mentioned in the discussion about the >> patch, but I don't see any reason for not back patching it stated. >> http://archives.postgresql.org/pgsql-hackers/2009-07/thrd5.php#00782 > > The patch that was being worked on at the time wouldn't have come close > to applying to 8.2, because the win32 shmem code got rearranged very > substantially for 8.3. However, AIUI it's the same underlying > technology, so in principle it could be fixed the same way. Right - thats what i was expecting to see. > If we take seriously the proposition that we're still supporting 8.2 > on Windows, we probably ought to do something about that. If we don't, > we need to officially deprecate that version. That's the last non-msvc++ version. Personally I'd love to drop it so i can get rid of mingw/msys and move entirely to vc++ for Win32 and Win64. I'm not so sure it's fair to the users though. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Dave Page <dpage@pgadmin.org> writes: > On 5/2/10, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If we take seriously the proposition that we're still supporting 8.2 >> on Windows, we probably ought to do something about that. If we don't, >> we need to officially deprecate that version. > That's the last non-msvc++ version. Personally I'd love to drop it so > i can get rid of mingw/msys and move entirely to vc++ for Win32 and > Win64. > I'm not so sure it's fair to the users though. Well, we did promise that Windows 8.2 would have the same lifespan as 8.2 on other platforms: http://www.postgresql.org/about/news.865 The planned EOL is only a year and a half away anyway. OTOH, if it's doubling your effort to build Windows binary distributions, maybe it's not worth continuing to support it. regards, tom lane
On Sun, May 2, 2010 at 7:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dave Page <dpage@pgadmin.org> writes: >> On 5/2/10, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'm not so sure it's fair to the users though. > > Well, we did promise that Windows 8.2 would have the same lifespan as > 8.2 on other platforms: > http://www.postgresql.org/about/news.865 Right. > The planned EOL is only a year and a half away anyway. OTOH, if it's > doubling your effort to build Windows binary distributions, maybe > it's not worth continuing to support it. Probably 66% of the effort in a back branch release is the 8.2 installer for me. The 8.3 MSI installer build automates (or eliminates) much of the harder manual work, and the one-clicks are 100% automated - the effort there has been put in over the longer term to develop them in a maintainable way. But... unless there are other good reasons (like we actually can't fix things without serious effort, rather than we just can't be bothered), I don't want my time to be the cause of us dropping it early. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company