
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

                                mbjsql@hotmail.com



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com


Mon, 23 Apr 2001 11:41:31 -0500
"Mauricio Breternitz" <mbjsql@hotmail.com>
concurrent Postgres on NUMA - howto ? 
"Mauricio Breternitz" <mbjsql@hotmail.com> writes:
> 	My concern is whether that is enough to maintain consistency
> in the buffer cache

No, it isn't --- for one thing, WriteBuffer wouldn't cause other
backends to update their copies of the page.  At the very least you'd
need to synchronize where the LockBuffer calls are, not where
WriteBuffer is called.

I really question whether you want to do anything like this at all.
Seems like accessing the shared buffers right where they are will be
fastest; your approach will entail a huge amount of extra data copying.
Considering that a backend doesn't normally touch every byte on a page
that it accesses, I wouldn't be surprised if full-page copying would
net out to being more shared-memory traffic, rather than less.

			regards, tom lane

Mon, 23 Apr 2001 19:43:05 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: concurrent Postgres on NUMA - howto ? 