Folks: I'm planning a port of Postgres to a multiprocessor
architecture in which all nodes have both local memory
and fast access to a shared memory. Shared memory it more
expensive than local memory.
My intent is to put the shmem & lock structures in
shared memory, but use a copy-in / copy-out approach to
maintain coherence in the buffer cache:- copy buffer from shared memroy on buffer allocate- write back buffer to shared
memorywhen it is dirtied.
Is that enough ?
The idea sketch is as follows (mostly, changes
contained in storage/buffer/bufmgr.c):
-change BufferAlloc, etc, to create a node-local copy
of the buffer (from shared memory). Copy both the BufferDesc
entry and the buffer->data array
-change WriteBuffer to copy the (locally changed) bufferto shared memory (this is the point in which the BM_DIRTYbit is
set).[ I am assuming the buffer is locked & thisis a safe time to make the buffer visible to other backends].
[Assume, for this discussion, that the sem / locks structs in
shared memory have been ported & work ]. Ditto for the hash access.
My concern is whether that is enough to maintain consistency
in the buffer cache (i.e, are there other places in the code
where a backend might have a leftover pointer to somewhere in
the buffer cache ? ) Because, in the scheme above, the buffer
cache is not directly accessible to the backend except via this
copy in / copy -out approach.
[BTW, I think this might be a way of providing a 'cluster'
version of Postgers, by using some global communication module to
obtain/post the 'buffer cache' values]
thanks regards Mauricio
Mauricio Breternitz Jr, Ph.D.
Times N Systems Inc.
1908 Kramer Ln, Braker Building B, Suite P
Austin, TX 78758
phone (512) 977 5368
mauriciob@timesn.com
Mauricio Breternitz Jr, Ph.D.
Times N Systems Inc.
1908 Kramer Ln, Braker Building B, Suite P
Austin, TX 78758
phone (512) 977 5368
mauriciob@timesn.com