Buffer manager (was Re: relcache refcount)

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Buffer manager (was Re: relcache refcount)
Date: 2004-05-24 04:14:40
Message-ID: 20040524041440.GA2668@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 13, 2004 at 09:43:42AM -0400, Tom Lane wrote:

> BTW, what are your plans for state saving/reversion for the lock manager
> and buffer manager?

Ok, I have skimmed through the buffer manager code. At first I thought
I'd have to set something up in shared memory for this, but then I
noticed that every backend keeps a local reference count, and modifies
the shared counter only when the local one raises from zero, or drops to
zero.

Also, the number of buffers does not change while the server is running.

So I see two ways of handling this:

1. Keep an array of local refcounts for all buffers, for each subtrans.
At subtrans start, a new array is allocated and filled with current
local refcounts. At subtrans abort, we check if any count would go to
zero while restoring; if so, decrement the shared counter. At subtrans
commit, drop the saved array.

The problem with this approach is that we allocate a large array which
likely will be almost full of zeros.

2. Keep a more elaborate struct, where each buffer get its local count
saved only if its nonzero. Thus we don't have to allocate a large
amount of memory.

Comments? Opinions? Which one do you think is better? Any completely
different idea?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Coge la flor que hoy nace alegre, ufana. ¿Quién sabe si nacera otra mañana?"

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2004-05-24 07:06:33 Re: Latest requests from IRC
Previous Message Bruce Momjian 2004-05-24 03:23:49 Re: Unicode upper/lower solution proposal