Re: FATAL: could not reattach to shared memory (Win32) - Mailing list pgsql-general

From Tom Lane
Subject Re: FATAL: could not reattach to shared memory (Win32)
Date
Msg-id 3091.1187977837@sss.pgh.pa.us
Whole thread Raw
In response to Re: FATAL: could not reattach to shared memory (Win32)  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: FATAL: could not reattach to shared memory (Win32)  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-general
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> There are a few old bits of code that still use MAKE_PTR/MAKE_OFFSET,
>> but I think it's mostly just that no one's bothered to rewrite the code
>> for SHM_QUEUE linked lists.  The vast majority of our shmem structures
>> use regular pointers, and have for years.

> Ah, I happened to be recently in that code so I was mislead.

IIRC, the reason for not bothering to change the SHM_QUEUE code (other
than inertia) was that it's a generic linked list package, and so if
it wasn't storing SHMEM_OFFSETs it'd be storing "void *"'s, and so there
didn't seem to be any traction to be gained in terms of compiler error
detection capability.  However, if both you and Alvaro were confused
about the liveness of that coding convention, maybe it'd be worth making
a push to eliminate all trace of MAKE_PTR/MAKE_OFFSET.  TODO for 8.4?

            regards, tom lane

pgsql-general by date:

Previous
From: Shelby Cain
Date:
Subject: Re: FATAL: could not reattach to shared memory (Win32)
Next
From: Oleg Bartunov
Date:
Subject: Re: Can tsearch do some basic text mining