Re: postgres crashes - could not reattach to shared memory - Mailing list pgsql-general

From Dave Page
Subject Re: postgres crashes - could not reattach to shared memory
Date
Msg-id v2w937d27e11005021131x1bfe254ftc33c76a42ea12e87@mail.gmail.com
Whole thread Raw
In response to Re: postgres crashes - could not reattach to shared memory  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: postgres crashes - could not reattach to shared memory  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Tracking down log segment corruption
Next
From: Gordon Shannon
Date:
Subject: Re: Tracking down log segment corruption