Re: FATAL: could not reattach to shared memory (Win32)
От | Gregory Stark |
---|---|
Тема | Re: FATAL: could not reattach to shared memory (Win32) |
Дата | |
Msg-id | 871wdszodo.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: FATAL: could not reattach to shared memory (Win32) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: