Re: Protecting against unexpected zero-pages: proposal

From: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Protecting against unexpected zero-pages: proposal
Date: 2010-11-07 04:23:15
Message-ID: AANLkTikOxS94M3SVrMFWL+LNJUCHEEepG17=KD6nF9wn@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 6, 2010 at 11:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> writes:
> > .) The basic idea is to have a magic number in every PageHeader before it
> is
> > written to disk, and check for this magic number when performing page
> > validity
> > checks.
>
> Um ... and exactly how does that differ from the existing behavior?
>

Right now a zero filled page considered valid, and is treated as a new page;
PageHeaderIsValid()->/* Check all-zeroes case */, and PageIsNew(). This
means that looking at a zero-filled page on disk (say after a crash) does
not give us any clue if it was indeed left zeroed by Postgres, or did
FS/storage failed to do their job.

With the proposed change, if it is a valid page (a page actually written by
Postgres) it will either have a sensible LSN or the magic-LSN; the LSN will
never be zero. OTOH, if we encounter a zero filled page ( => LSN={0,0)} ) it
clearly would implicate elements outside Postgres in making that page zero.

> The amount of fragility introduced by the assumptions you have to make
> for this seems to me to be vastly riskier than the risk you are trying
> to respond to.
>
>
I understand that it is a pretty low-level change, but IMHO the change is
minimal and is being applied in well understood places. All the assumptions
listed have been effective for quite a while, and I don't see these
assumptions being affected in the near future. Most crucial assumptions we
have to work with are, that XLogPtr{n, 0xFFFFFFFF} will never be used, and
that mdextend() is the only place that extends a relation (until we
implement an md.c sibling, say flash.c or tape.c; the last change to md.c
regarding mdextend() was in January 2007).

Only mdextend() and PageHeaderIsValid() need to know this change in
behaviour, and all the other APIs work and behave the same as they do now.

This change would increase the diagnosability of zero-page issues, and help
the users point fingers at right places.

Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com

singh(dot)gurjeet(at){ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-11-07 05:04:27 Re: Protecting against unexpected zero-pages: proposal
Previous Message Daniel Farina 2010-11-07 03:16:18 Re: ALTER TABLE ... IF EXISTS feature?