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

Re: [PATCHES] Load distributed checkpoint patch

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Load distributed checkpoint patch
Date: 2006-12-20 16:06:46
Message-ID: 200612201606.kBKG6kE15233@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
ITAGAKI Takahiro wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> 
> > OK, if I understand correctly, instead of doing a buffer scan, write(),
> > and fsync(), and recyle the WAL files at checkpoint time, you delay the
> > scan/write part with the some delay.
> 
> Exactly. Actual behavior of checkpoint is not changed by the patch. Compared
> with existing checkpoints, it just takes longer time in scan/write part.
> 
> > Do you use the same delay autovacuum uses?

Sorry, I meant bgwriter delay, not autovauum.

> What do you mean 'the same delay'? Autovacuum does VACUUM, not CHECKPOINT.
> If you think cost-based-delay, I think we cannot use it here. It's hard to
> estimate how much checkpoints delay by cost-based sleeping, but we should
> finish asynchronous checkpoints by the start of next checkpoint. So I gave
> priority to punctuality over load smoothing.

OK.

> > As I remember, often the checkpoint is caused because
> > we are using the last WAL file.  Doesn't this delay the creation of new
> > WAL files by renaming the old ones to higher numbers (we can't rename
> > them until the checkpoint is complete)?
> 
> Checkpoints should be done by the next one, so we need WAL files for two
> checkpoints. It is the same as now.

Ah, OK, so we already reserve a full set of WAL files while we are
waiting for the checkpoint to complete.

-- 
  Bruce Momjian   bruce(at)momjian(dot)us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2006-12-20 16:07:34
Subject: Re: effective_cache_size vs units
Previous:From: Andrew DunstanDate: 2006-12-20 14:49:32
Subject: Re: [HACKERS] Enums patch v2

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-12-20 16:20:16
Subject: Re: column ordering, was Re: [PATCHES] Enums patch
Previous:From: Andrew DunstanDate: 2006-12-20 14:49:32
Subject: Re: [HACKERS] Enums patch v2

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