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 memory when it is dirtied.
Is that enough ?
The idea sketch is as follows (mostly, changes
contained to 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) buffer
to shared memory (this is the point in which the BM_DIRTY
bit is set). [ I am assuming the buffer is locked & this
is 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
[EMAIL PROTECTED]
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
