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?  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Status on Jan Wieck
Следующее
От: José Soares
Дата:
Сообщение: Re: [HACKERS] All things equal, we are still alot slower then MySQL?