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

Re: 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-patches(at)postgresql(dot)org
Subject: Re: Load distributed checkpoint patch
Date: 2006-12-19 17:00:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
ITAGAKI Takahiro wrote:
> This is a patch for load distributed checkpoint discussed in
> Only write() calls are smoothed, fsync() are not.
> Existing checkpoint method is called "immediate checkpoint" in the patch,
> and the new method called "asynchronous checkpoint".
> I'm working on more robust control of checkpoint progress. WAL are written
> a lot just after checkpoints because of full-page-writes and decreases
> gradually. Linear control seems to be not enough in some cases.
> Comments, suggestions and testing are appreciated.

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.  Do you use the same delay
autovacuum uses?  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)?

  Bruce Momjian   bruce(at)momjian(dot)us

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

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-12-19 17:01:44
Subject: Re: Autovacuum Improvements (was: Second attempt,
Previous:From: Stephen FrostDate: 2006-12-19 16:59:32
Subject: ERROR: tuple concurrently updated

pgsql-patches by date

Next:From: Tom DunstanDate: 2006-12-20 01:23:02
Subject: Re: Enums patch v2
Previous:From: Martijn van OosterhoutDate: 2006-12-19 16:25:04
Subject: Re: column ordering, was Re: [PATCHES] Enums patch v2

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