concurrent postgres in NUMA cluster postgres - design OK ?

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 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) 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

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(at)timesn(dot)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(at)timesn(dot)com