"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
