Re: Avoiding unnecessary reads in recovery

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoiding unnecessary reads in recovery
Date: 2007-04-27 14:05:43
Message-ID: 20070427140543.GI4645@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> >Heikki Linnakangas wrote:
> >
> >>What we could have is the semantics of "Return a buffer, with either
> >>correct contents or completely zeroed out". It would act just like
> >>ReadBuffer if the buffer was already in memory, and zero out the page
> >>otherwise. That's a bit strange semantics to have, but is simple to
> >>implement and works for the use-cases we've been talking about.
> >
> >Huh, why does that work in the case where the recovery code reads a
> >page, then evicts it because of memory pressure, and later needs to read
> >it again?
>
> I don't understand the problem. You only use ReadOrZeroBuffer when
> you're going to replace the contents entirely, and don't care about the
> old contents. If you want to read something in, you use ReadBuffer.

Oh, the recovery code selects which one to call based on the "init"
param, which is on the first hunk of the diff :-) I forgot that, I was
just thinking in your description above.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-04-27 14:18:47 Re: Feature freeze progress report
Previous Message Tom Lane 2007-04-27 14:05:34 Re: [Fwd: PGBuildfarm member narwhal Branch HEAD Status changed from OK to InstallCheck failure]