From: Kenneth Marshall <ktm@rice.edu>
To: Zeugswetter Andreas ADI SD <ZeugswetterA@spardat.at>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org, Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp>
Cc: pgsql-patches@postgresql.org
Subject: Re: [HACKERS] Full page writes improvement, code update
Date: Wed, 25 Apr 2007 07:56:49 -0500
Message-ID: <20070425125649.GD19464@it.is.rice.edu> (raw)
In-Reply-To: <E1539E0ED7043848906A8FF995BDA57901F40143@m0143.s-mxs.net>
References: <460886E8.6040907@oss.ntt.co.jp>
<462D5A23.9060706@oss.ntt.co.jp>
<E1539E0ED7043848906A8FF995BDA57901F3FFCC@m0143.s-mxs.net>
<200704240831.42873.josh@agliodbs.com>
<E1539E0ED7043848906A8FF995BDA57901F40143@m0143.s-mxs.net>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ktm@rice.edu, ZeugswetterA@spardat.at, josh@agliodbs.com, suzuki.koichi@oss.ntt.co.jp, pgsql-patches@postgresql.org
Subject: Re: [HACKERS] Full page writes improvement, code update
In-Reply-To: <20070425125649.GD19464@it.is.rice.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox