Re: Avoiding adjacent checkpoint records

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Avoiding adjacent checkpoint records
Date: 2012-06-08 16:24:56
Message-ID: 4FD1E10802000025000481F5@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> if the database has checkpointed

I haven't been exactly clear on the risks about which Tom and Robert
have been concerned; is it a question about whether we change the
meaning of these settings to something more complicated?:

checkpoint_segments (integer)
Maximum number of log file segments between automatic WAL
checkpoints

checkpoint_timeout (integer)
Maximum time between automatic WAL checkpoints

I can see possibly changing the latter when absolutely nothing has
been written to WAL since the last checkpoint, although I'm not sure
that should suppress flushing dirty pages (e.g., from hinting) to
disk. Such a change seems like it would be of pretty minimal
benefit, though, and not something for which it is worth taking on
any risk at all. Any other change to the semantics of these
settings seems ill advised on the face of it.

... or am I not grasping the issue properly?

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2012-06-08 17:01:12 Re: Checkpointer on hot standby runs without looking checkpoint_segments
Previous Message Robert Haas 2012-06-08 15:24:22 Re: Avoiding adjacent checkpoint records