Re: Protecting against unexpected zero-pages: proposal

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Protecting against unexpected zero-pages: proposal
Date: 2010-11-09 14:28:36
Message-ID: AANLkTikuuLMFL0gv9XL7=jfxHQ8CYRfgXC_UoLC9N-KA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 9, 2010 at 8:45 AM, Greg Stark <gsstark(at)mit(dot)edu> wrote:

> But buffering the page only means you've got some consistent view of
> the page. It doesn't mean the checksum will actually match the data in
> the page that gets written out. So when you read it back in the
> checksum may be invalid.

I was assuming that if the code went through the trouble to buffer the
shared page to get a "stable, non-changing" copy to use for
checksumming/writing it, it would write() the buffered copy it just
made, not the original in shared memory... I'm not sure how that
write could be in-consistent.

a.

--
Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-11-09 14:59:59 Re: W3C Specs: Web SQL
Previous Message Heikki Linnakangas 2010-11-09 14:23:25 Re: CLUSTER can change t_len