On Sat, Jan 28, 2012 at 1:52 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Also, I think the general approach is wrong. The only reason to have
>> these pages in shared memory is that we can control access to them to
>> prevent write/write and read/write corruption. Since these pages are
>> never written, they don't need to be in shared memory. Just read
>> each page into backend-local memory as it is needed, either
>> palloc/pfree each time or using a single reserved block for the
>> lifetime of the session. Let the kernel worry about caching them so
>> that the above mentioned reads are cheap.
>
> Will think on that.
For me, there are arguments both ways as to whether it should be in
shared or local memory.
The one factor that makes the answer "shared" for me is that its much
easier to reuse existing SLRU code. We dont need to invent a new way
of cacheing/access etc. We just rewire what we already have. So
overall, the local/shared debate is much less important that the
robustness/code reuse angle. That's what makes this patch fairly
simple.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
