Re: Dynamically sizing FSM?

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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