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

Re: RC2 and open issues

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


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-12-23 03:52:31
Subject: Re: Regression (semi)fix for netbsd-mac68k
Previous:From: RĂ©mi ZaraDate: 2004-12-22 23:37:36
Subject: Re: Regression (semi)fix for netbsd-mac68k

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