Re: [HACKERS] why do shmem attach?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] why do shmem attach? |
Дата | |
Msg-id | 13479.937835049@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] why do shmem attach? (Vadim Mikheev <vadim@krs.ru>) |
Ответы |
Re: [HACKERS] why do shmem attach?
|
Список | pgsql-hackers |
Vadim Mikheev <vadim@krs.ru> writes: > Though, AttachSharedMemoryAndSemaphores(): > if (key == PrivateIPCKey) > { > CreateSharedMemoryAndSemaphores(key, 16); > return; > } > ... and useless shmem attachment stuff follows after this ... That path is used for a standalone backend. Is that useless? > Cleanup is still required, but subj is closed, thanks -:) I don't think it's worth messing with either. It'd be nice for code beautification purposes to (a) combine the three shared-mem segments we currently have into one, and (b) rely on the postmaster's having attached the segment, so that all backends will see it at the same location in their address space, which would let us get rid of the MAKE_OFFSET/MAKE_PTR cruft. But getting the full benefit would require cleaning up a lot of code, and it just doesn't seem like a high-priority task. I'm also a little worried that we'd be sacrificing portability --- some day we might be glad that we can move those segments around... regards, tom lane
В списке pgsql-hackers по дате отправления: