Re: Bug: Buffer cache is not scan resistant - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Bug: Buffer cache is not scan resistant
Date
Msg-id 200704022315.l32NFiP18580@momjian.us
Whole thread Raw
In response to Re: Bug: Buffer cache is not scan resistant  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
"test" version, but I am putting in the queue so we can track it there.

Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


Simon Riggs wrote:
> On Mon, 2007-03-12 at 09:14 +0000, Simon Riggs wrote:
> > On Mon, 2007-03-12 at 16:21 +0900, ITAGAKI Takahiro wrote:
> 
> > > With the default
> > > value of scan_recycle_buffers(=0), VACUUM seems to use all of buffers in pool,
> > > just like existing sequential scans. Is this intended?
> > 
> > Yes, but its not very useful for testing to have done that. I'll do
> > another version within the hour that sets N=0 (only) back to current
> > behaviour for VACUUM.
> 
> New test version enclosed, where scan_recycle_buffers = 0 doesn't change
> existing VACUUM behaviour.
> 
> -- 
>   Simon Riggs             
>   EnterpriseDB   http://www.enterprisedb.com
> 

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Interaction of PITR backups and Bulkoperationsavoiding WAL
Next
From: Mark Dilger
Date:
Subject: Re: Bug in UTF8-Validation Code?