Re: Simplifying replication

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Simplifying replication
Date: 2010-11-12 14:05:02
Message-ID: 201011121405.oACE52v27305@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Thu, Nov 11, 2010 at 10:13 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Robert Haas wrote:
> >> On Thu, Oct 28, 2010 at 1:13 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >> >
> >> >> I sort of agree with you that the current checkpoint_segments
> >> >> parameter is a bit hard to tune, at least if your goal is to control
> >> >> the amount of disk space that will be used by WAL files. ?But I'm not
> >> >> sure your proposal is better. ?Instead of having a complicated formula
> >> >> for predicting how much disk space would get used by a given value for
> >> >> checkpoint_segments, we'd have a complicated formula for the amount of
> >> >> WAL that would force a checkpoint based on max_wal_size.
> >> >
> >> > Yes, but the complicated formula would then be *in our code* instead of
> >> > being inflicted on the user, as it now is.
> >>
> >> I don't think so - I think it will just be inflicted on the user in a
> >> different way. ?We'd still have to document what the formula is,
> >> because people will want to understand how often a checkpoint is going
> >> to get forced.
> >>
> >> So here's an example of how this could happen. ?Someone sets
> >> max_wal_size = 480MB. ?Then, they hear about the
> >> checkpoint_completion_target parameter, and say, ooh, goody, let me
> >> boost that. ?So they raise it from 0.5 to 0.9. ?Now, all of a sudden,
> >> they're getting more frequent checkpoints. ?Performance may get worse
> >
> > Uh, checkpoint_completion_target only controls flushing of buffers
> > between checkpoints, not the frequency of checkpoints.
>
> According to the formula in our fine documentation, if you increase
> checkpoint_completion_target, the maximum number of WAL files also
> increases. This makes sense: the files from the last checkpoint can't
> be removed until further along into the next cycle. Therefore, if you
> wanted to increase the checkpoint_completion_target while keeping the
> maximum amount of WAL on disk the same, you'd need to trigger
> checkpoints more frequently.

Do we recycle WAL files between checkpoints or just at checkpoint time?
I thought it was only at checkpoint time.

Also, there was talk that a larger WAL directory would slow recovery,
but I thought it was only the time since the last checkpoint that
controlled that.

[ Again, sorry for my late reading of this and other threads. ]

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

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2010-11-12 14:07:27 Re: multi-platform, multi-locale regression tests
Previous Message Bruce Momjian 2010-11-12 14:02:40 Re: duplicate connection failure messages