Re: [HACKERS] why do shmem attach?

Tom Lane wrote:
>
> Vadim Mikheev <vadim(at)krs(dot)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