Re: [HACKERS] Full page writes improvement, code update - Mailing list pgsql-patches

From Kenneth Marshall
Subject Re: [HACKERS] Full page writes improvement, code update
Date
Msg-id 20070425125649.GD19464@it.is.rice.edu
Whole thread Raw
In response to Re: [HACKERS] Full page writes improvement, code update  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
List pgsql-patches
On Wed, Apr 25, 2007 at 10:00:16AM +0200, Zeugswetter Andreas ADI SD wrote:
>
> > > 1) To deal with partial/inconsisitent write to the data file at
> crash
> > > recovery, we need full page writes at the first modification to
> pages
> > > after each checkpoint.   It consumes much of WAL space.
> >
> > We need to find a way around this someday.  Other DBs don't
> > do this; it may be becuase they're less durable, or because
> > they fixed the problem.
>
> They eighter can only detect a failure later (this may be a very long
> time depending on access and verify runs) or they also write page
> images. Those that write page images usually write "before images" to a
> different area that is cleared periodically (e.g. during checkpoint).
>
> Writing to a different area was considered in pg, but there were more
> negative issues than positive.
> So imho pg_compresslog is the correct path forward. The current
> discussion is only about whether we want a more complex pg_compresslog
> and no change to current WAL, or an increased WAL size for a less
> complex implementation.
> Both would be able to compress the WAL to the same "archive log" size.
>
> Andreas
>
I definitely am in the camp of not increasing WAL size at all. If we
need a bit more complexity to ensure that, so be it. Any approach that
increases WAL volume would need to have an amazing benefit to make it
warranted. This certainly does not meet that criteria.

Ken


pgsql-patches by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Load distributed checkpoint V4.1
Next
From: Dave Page
Date:
Subject: Fix for MSVC header installation