Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > What do you think dynamic allocation from shared_buffers? ie, remove
> > a buffer page in the shared buffer pool and use the 8kB of memory
> > for another purpose.
>
> The problem with that is that (a) it creates more contention load on the
> shared buffer pool's management structures, and (b) if the chosen buffer
> is dirty then you have a different subsystem trying to do buffer I/O,
> which is at best a modularity bug and at worst a correctness or deadlock
> problem.
(a) I'm thinking that another hash table manages removed buffers.
Those buffers are marked with a new BM_SPECIAL flags or something
in BufferDesc->flags. We lookup them through module-specific hash
tables, so that buffer management hash tables (BufTable) are not used.
(b) Maybe we need a new abstraction layer under the buffer cache module.
A new "memory pool" subsystem will preserve our sanity.
+-- shared memory pool <- no more than "a bank of memory" +-- page cache <- currently called "shared buffers"
+--other modules using shared buffers
> It might represent a slightly
> inefficient use of the shared memory as a whole, but it helps preserve
> the developers' sanity ;-)
Yeah, I see. That's a bother :-)
But are there any requests to resize memory resources at runtime?
I want to use the dynamic shmem allocator for FSM and DSM
if available. If anyone want to use it for another purpose,
inventing it as a generalized form will be good.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center