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

Re: Page Checksums + Double Writes

From: Jesper Krogh <jesper(at)krogh(dot)cc>
To: Florian Weimer <fweimer(at)bfk(dot)de>
Cc: David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Page Checksums + Double Writes
Date: 2011-12-22 09:00:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 2011-12-22 09:42, Florian Weimer wrote:
> * David Fetter:
>> The issue is that double writes needs a checksum to work by itself,
>> and page checksums more broadly work better when there are double
>> writes, obviating the need to have full_page_writes on.
> How desirable is it to disable full_page_writes?  Doesn't it cut down
> recovery time significantly because it avoids read-modify-write cycles
> with a cold cache
What is the downsides of having full_page_writes enabled .. except from
log-volume? The manual mentions something about speed, but it is
a bit unclear where that would come from, since the full pages must
be somewhere in memory when being worked on anyway,.

Anyway, I have an archive_command that looks like:
archive_command = 'test ! -f /data/wal/%f.gz && gzip --fast < %p > 

It brings on along somewhere between 50 and 75% reduction in log-volume
with "no cost" on the production system (since gzip just occupices one 
of the
many cores on the system) and can easily keep up even during
quite heavy writes.

Recovery is a bit more tricky, because hooking gunzip into the command 
will cause the system to replay log, gunzip, read data, replay log cycle 
where the gunzip
easily could be done on the other logfiles while replay are being done 
on one.

So a "straightforward" recovery will cost in recovery time, but that can 
be dealt with.


In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-12-22 09:50:33
Subject: Re: Page Checksums + Double Writes
Previous:From: Simon RiggsDate: 2011-12-22 08:55:29
Subject: Re: Page Checksums + Double Writes

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