From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mauricio Breternitz" <mbjsql(at)hotmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: concurrent Postgres on NUMA - howto ? |
Date: | 2001-04-25 20:20:19 |
Message-ID: | 5631.988230019@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mauricio Breternitz" <mbjsql(at)hotmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Myers | 2001-04-25 20:25:45 | tables/indexes/logs on different volumes |
Previous Message | Tom Lane | 2001-04-25 19:25:34 | Re: refusing connections based on load ... |