Re: concurrent Postgres on NUMA - howto ?

"Mauricio Breternitz" <mbjsql@hotmail.com> writes:
>    Notice that WriteBuffer would just put the fresh copy of the page
> out in the shared space.
>    Other backends would get the latest  copy of the page when
> THEY execute BufferAlloc() afterwards.

You seem to be assuming that BufferAlloc is mutually exclusive across
backends --- it's not.  As I said, you'd have to look at transferring
data at LockBuffer time to make this work.

>    [Granted about the bandwidth needs. In my target arch,
> access to shmem is costlier and local mem, and cannot be done
> via pointers

What?  How do you manage to memcpy out of shmem then?

> (so a lot of code that might have pointers inside the
> shmem buffer may need to be tracked down & changed)].

You're correct, Postgres assumes it can have pointers to data inside the
page buffers.  I don't think changing that is feasible.  I find it hard
to believe that you can't have pointers to shmem though; IMHO it's not
shmem if it can't be pointed at.

> [Mhy reasoning for this is that a backend needs to have exclusive
> access to a buffer when it writes to it. And I think it 'advertises'
> the new buffer contents to the world when it sets the BM_DIRTY flag.]

No.  BM_DIRTY only advises the buffer manager that the page must
eventually be written back to disk; it does not have anything to do with
when/whether other backends see data changes within the page.  One more
time: LockBuffer is what you need to be looking at.
        regards, tom lane