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