Re: Logical to physical page mapping

From: Greg Stark <stark(at)mit(dot)edu>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <JanWieck(at)yahoo(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logical to physical page mapping
Date: 2012-10-28 13:43:07
Message-ID: CAM-w4HNsSVX3qAWqDTPK0iJmpgx3FPwSXcphDgzdH0=rj1ngRg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 27, 2012 at 8:41 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> If the pointers are stored as simple 4-byte integers, you probably could
> assume that they're atomic, and won't be torn.

Actually I think any fixed-size data structure would be fine. We're
worried about storage on disk here, not in memory. As long as the
pointers don't move around on the page then if part of a page is
written and part not then the only pointer possibly corrupted would be
the one spanning the old and new partial pages. That could be avoided
or detected easily.

The problem with torn pages on heap pages comes about only because
tuples are variable sized. As a result the page has line pointers that
need to be in sync with other parts of the page and vacuum needs to be
able to move tuples around on the page.

(Hm. I wonder if we could actually get away with only doing full page
writes on vacuum if we could detect torn pages from vacuum reliably
and avoid trying to read any data from them until they get restored by
the full page write.)

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-10-28 14:42:25 pgsql: Preserve intermediate .c files in coverage mode
Previous Message Peter Geoghegan 2012-10-28 11:36:01 Re: Should "select 'nan'::float = 'nan'::float;" return false as per IEEE 754