On Mon, Aug 14, 2017 at 3:58 PM, Guillaume Lelarge <guillaume@xxxxxxxxxxxx> wrote:
I know the documentation says this about a standalone database regarding the "archive_command" parameter.
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.
Although I did search for restartpoints and see this now:
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.
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.
"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.
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.
Don.
-- Don Seiler
www.seiler.us
www.seiler.us
