Re: Maximum number of WAL files in the pg_xlog directory

From: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Maximum number of WAL files in the pg_xlog directory
Date: 2015-04-01 10:00:51
Message-ID: 20150401120051.4ee202ae@erg
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

As I'm writing a doc patch for 9.4 -> 9.0, I'll discuss below on this formula
as this is the last one accepted by most of you.

On Mon, 3 Nov 2014 12:39:26 -0800
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> It looked to me that the formula, when descending from a previously
> stressed state, would be:
>
> greatest(1 + checkpoint_completion_target) * checkpoint_segments,
> wal_keep_segments) + 1 +
> 2 * checkpoint_segments + 1

It lacks a closing parenthesis. I guess the formula is:

greatest (
(1 + checkpoint_completion_target) * checkpoint_segments,
wal_keep_segments
)
+ 1 + 2 * checkpoint_segments + 1

> This assumes logs are filled evenly over a checkpoint cycle, which is
> probably not true because there is a spike in full page writes right after
> a checkpoint starts.
>
> But I didn't have a great deal of confidence in my analysis.

The only problem I have with this formula is that considering
checkpoint_completion_target ~ 1 and wal_keep_segments = 0, it becomes:

4 * checkpoint_segments + 2

Which violate the well known, observed and default one:

3 * checkpoint_segments + 1

A value above this formula means the system can not cope with the number of
file to flush. The doc is right about that:

If, due to a short-term peak of log output rate, there
are more than 3 * <varname>checkpoint_segments</varname> + 1
segment files, the unneeded segment files will be deleted

The formula is wrong in the doc when wal_keep_segments <> 0

> The first line reflects the number of WAL that will be retained as-is,

I agree with this files MUST be retained: the set of checkpoint_segments WALs
beeing flushed and the checkpoint_completion_target ones written in
the meantime.

> the second is the number that will be recycled for future use before starting
> to delete them.

disagree cause the WAL files beeing written are actually consuming recycled
WALs in the meantime.

Your formula expect written files are created and recycled ones never touched,
leading to this checkpoint_segment + 1 difference between formulas.

> My reading of the code is that wal_keep_segments is computed from the
> current end of WAL (i.e the checkpoint record), not from the checkpoint
> redo point. If I distribute the part outside the 'greatest' into both
> branches of the 'greatest', I don't get the same answer as you do for
> either branch.

So The formula, using checkpoint_completion_target=1, should be:

greatest (
checkpoint_segments,
wal_keep_segments
)
+ 2 * checkpoint_segments + 1

Please find attached to this email a documentation patch for 9.4 using this
formula.

Regards,
--
Jehan-Guillaume de Rorthais
Dalibo
http://www.dalibo.com

Attachment Content-Type Size
doc-max_number_of_wal-1.diff text/x-patch 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-04-01 10:30:40 Re: Parallel Seq Scan
Previous Message Fujii Masao 2015-04-01 09:38:31 Re: pg_basebackup may fail to send feedbacks.