Re: Redesigning checkpoint_segments

On Mon, Mar 16, 2015 at 11:05 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> On Mon, Feb 23, 2015 at 8:56 AM, Heikki Linnakangas <
> hlinnakangas(at)vmware(dot)com> wrote:
>
>>
>> Everyone seems to be happy with the names and behaviour of the GUCs, so
>> committed.
>
>
>
> The docs suggest that max_wal_size will be respected during archive
> recovery (causing restartpoints and recycling), but I'm not seeing that
> happening. Is this a doc bug or an implementation bug?
>

I think the old behavior, where restartpoints were driven only by time and
not by volume, was a misfeature. But not a bug, because it was documented.

One of the points of max_wal_size and its predecessor is to limit how big
pg_xlog can grow. But running out of disk space on pg_xlog is no more fun
during archive recovery than it is during normal operations. So why
shouldn't max_wal_size be active during recovery?

It seems to be a trivial change to implement that, although I might be
overlooking something subtle (pasted below, also attached)

--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -10946,7 +10946,7 @@ XLogPageRead(XLogReaderState *xlogreader,
XLogRecPtr targetPagePtr, int reqLen,
* Request a restartpoint if we've replayed too much xlog
since the
* last one.
*/
- if (StandbyModeRequested && bgwriterLaunched)
+ if (bgwriterLaunched)
{
if (XLogCheckpointNeeded(readSegNo))
{

This keeps pg_xlog at about 67% of max_wal_size during archive recovery
(because checkpoint_completion_target is accounted for but goes unused)

Or, if we do not wish to make this change in behavior, then we should fix
the docs to re-instate this distinction between archive recovery and
standby.

diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index f4083c3..ebc8baa 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -589,7 +589,8 @@
master because restartpoints can only be performed at checkpoint
records.
A restartpoint is triggered when a checkpoint record is reached if at
least <varname>checkpoint_timeout</> seconds have passed since the last
- restartpoint, or if WAL size is about to exceed
+ restartpoint. In standby mode, a restartpoint is also triggered if
+ WAL size is about to exceed
<varname>max_wal_size</>.
</para>

Cheers,

Jeff