Re: Logical to physical page mapping - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Logical to physical page mapping
Date
Msg-id CAM-w4HNsSVX3qAWqDTPK0iJmpgx3FPwSXcphDgzdH0=rj1ngRg@mail.gmail.com
Whole thread Raw
In response to Re: Logical to physical page mapping  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Sat, Oct 27, 2012 at 8:41 PM, Heikki Linnakangas
<hlinnakangas@vmware.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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Should "select 'nan'::float = 'nan'::float;" return false as per IEEE 754
Next
From: Aaron Sheldon
Date:
Subject: Re: Measure types in pg