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

Re: Load Distributed Checkpoints, take 3

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Load Distributed Checkpoints, take 3
Date: 2007-06-26 08:28:58
Message-ID: 4680CE4A.3080906@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane wrote:
> Hmm.  But if we're going to do that, we might as well have a checkpoint
> for our troubles, no?  The reason for the current design is the
> assumption that a bgwriter_all scan is less burdensome than a
> checkpoint, but that is no longer true given this rewrite.

Per comments in CreateCheckPoint, another  also skip the extra 
checkpoints to avoid writing two checkpoints to the same page, risking 
losing both on a crash:

> 	 * If this isn't a shutdown or forced checkpoint, and we have not inserted
> 	 * any XLOG records since the start of the last checkpoint, skip the
> 	 * checkpoint.	The idea here is to avoid inserting duplicate checkpoints
> 	 * when the system is idle. That wastes log space, and more importantly it
> 	 * exposes us to possible loss of both current and previous checkpoint
> 	 * records if the machine crashes just as we're writing the update.
> 	 * (Perhaps it'd make even more sense to checkpoint only when the previous
> 	 * checkpoint record is in a different xlog page?)

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-patches by date

Next:From: ITAGAKI TakahiroDate: 2007-06-26 11:19:22
Subject: pgstat_drop_relation bugfix
Previous:From: Tom LaneDate: 2007-06-26 04:08:49
Subject: Re: remove unused "caller" arg from stringToQualifiedNameList

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