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

From Gregory Stark
Subject Re: FATAL: could not reattach to shared memory (Win32)
Date
Msg-id 871wdszodo.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: FATAL: could not reattach to shared memory (Win32)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

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

It would also make using gdb to look at the lock queues a bit less of a pain.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: PG Seg Faults Performing a Query
Next
From: Vivek Khera
Date:
Subject: Re: PostgreSQL vs Firebird feature comparison finished