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.