Re: [HACKERS] Full page writes improvement, code update

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Koichi Suzuki <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Full page writes improvement, code update
Date: 2007-04-25 12:56:49
Message-ID: 20070425125649.GD19464@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-04-25 13:05:32 Re: autovacuum does not start in HEAD
Previous Message Heikki Linnakangas 2007-04-25 12:48:51 Avoiding unnecessary reads in recovery

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2007-04-25 13:05:32 Re: autovacuum does not start in HEAD
Previous Message Heikki Linnakangas 2007-04-25 10:45:22 Re: Load distributed checkpoint V4.1