Re: [HACKERS] why do shmem attach?

Tom Lane wrote:
> 
> 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?

Isn't key equal to PrivateIPCKey for standalone backend?

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

I would try to use more than one segment for buffer pool if
max seg size is not enough for all buffers.

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

We can't. MAKE_OFFSET/MAKE_PTR was used because of after
fork/exec/shmat backend' ShmemBase was different from
postmaster' one. But we can't move *BufferDescriptors 
if some running backend already uses BufferDescriptors.
But I agreed - this is not high-priority task -:)

Vadim