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

From Tom Lane
Subject Re: [HACKERS] why do shmem attach?
Date
Msg-id 13849.937838191@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] why do shmem attach?  (Vadim Mikheev <vadim@krs.ru>)
List pgsql-hackers
Vadim Mikheev <vadim@krs.ru> writes:
>> 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.

Ah, that would be a nice end-run around kernels with small SHMMAX,
wouldn't it?

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

Right, we can't relocate a segment within the address space of
an already-running backend.  What I meant was that being able
to put it at different addresses in different backends might be
needed again someday, even though right now we don't need it.

> But I agreed - this is not high-priority task -:)

Yup.  Plenty of high-priority ones, too...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] couldn't rollback cache ?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] why do shmem attach?