| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Richard Huxton <dev(at)archonet(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: RC2 and open issues | 
| Date: | 2004-12-23 00:05:27 | 
| Message-ID: | 1103760327.2891.21.camel@localhost.localdomain | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Tue, 2004-12-21 at 15:26, Tom Lane wrote:
> Richard Huxton <dev(at)archonet(dot)com> writes:
> > However, one thing you can say is that if block B hasn't been written to 
> > since you last checked, then any blocks older than that haven't been 
> > written to either.
> 
> [ itch... ]  Can you?  I don't recall exactly when a block gets pushed
> up the ARC list during a ReadBuffer/WriteBuffer cycle, but at the very
> least I'd have to say that this assumption is vulnerable to race
> conditions.
> 
An intriguing idea: after some thought this would only be true if all
block accesses were writes. A block can be re-read (but not written),
causing it to move to the MRU of T2, thus moving it ahead of other dirty
buffers.
Forgive me: the conveyor belt analogy only applies when blocks on the
buffer list haven't been touched *at all*. i.e. if they are hit only
once (on T1) or twice (T2) they then just move down towards the LRU and
roll off when they get there.
-- 
Best Regards, Simon Riggs
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-12-23 03:52:31 | Re: Regression (semi)fix for netbsd-mac68k | 
| Previous Message | Rémi Zara | 2004-12-22 23:37:36 | Re: Regression (semi)fix for netbsd-mac68k |