Skip site navigation (1) Skip section navigation (2)

Re: concurrent Postgres on NUMA - howto ?

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 (view raw or flat)
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

In response to

pgsql-hackers by date

Next:From: Nathan MyersDate: 2001-04-25 20:25:45
Subject: tables/indexes/logs on different volumes
Previous:From: Tom LaneDate: 2001-04-25 19:25:34
Subject: Re: refusing connections based on load ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group