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, whole thread or download thread mbox)
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

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-2017 The PostgreSQL Global Development Group