2017-08-14 23:08 GMT+02:00 Don Seiler <don@xxxxxxxxx>:
On Mon, Aug 14, 2017 at 3:58 PM, Guillaume Lelarge <guillaume@xxxxxxxxxxxx> wrote:The server removes the WAL files it doesn't need anymore, weither it is a primary (after a checkpoint) or a secondary node (after a restartpoint). That's just part of the usual process.I know the documentation says this about a standalone database regarding the "archive_command" parameter."It is important that the archive command return zero exit status if and only if it succeeds. Upon getting a zero result, PostgreSQL will assume that the file has been successfully archived, and will remove or recycle it."
However on a standby, my understanding is that the archive_command parameter is not used. I know for sure that it would fail on the standby that I'm looking at.
Well, then, you need to check your facts :) Since 9.5, a standy can archive WAL files. See archive_mode and its "new" value : always.
Although I did search for restartpoints and see this now:In archive recovery or standby mode, the server periodically performs restartpoints which are similar to checkpoints in normal operation: the server forces all its state to disk, updates the pg_control file to indicate that the already-processed WAL data need not be scanned again, and then recycles any old log segment files in pg_xlog directory.
So I guess that's all the info I need then. Is there any to control that behavior if (for reasons I can't think of right now other than cascading standby) I wanted to delay that file recycling? Just curious.
I guess checkpoint_timeout is what you're looking for.
--
Guillaume.
