Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group