Re: [HACKERS] why do shmem attach? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] why do shmem attach?
Date
Msg-id 13479.937835049@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] why do shmem attach?  (Vadim Mikheev <vadim@krs.ru>)
Responses Re: [HACKERS] why do shmem attach?  (Bruce Momjian <maillist@candle.pha.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Status on Jan Wieck
Next
From: José Soares
Date:
Subject: Re: [HACKERS] All things equal, we are still alot slower then MySQL?