Tom Lane <[EMAIL PROTECTED]> 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.

ITAGAKI Takahiro
NTT Open Source Software Center

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to