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