Alvaro Herrera wrote:
> Duco Fijma wrote:
>
>> Please allow me to rephrase a question I asked on this list some time
>> ago. Could somebody shine some light on what exactly influences the
>> value of the %r parameter in the restore_command (as used in
>> recovery.conf)? I'm using this in a hot-standby-configuration in
>> combination with pg_standby and _sometimes_ my archive on shipped
>> transaction logs grow really huge. The value of %r then never changes
>> any more in subsequent calls of the restore_command, causing pg_standby
>> to not delete any WAL segment anymore.
>
> AFAIR %r is supposed to mean "the earliest segment that can safely be
> removed"(*). If there's a lot of backlog then perhaps the recovery
> process has stopped replaying WAL segments for some reason. Is there
> anything unusual in the slave logs?
As far as I remember (the server is at the moment running OK) the new
WAL segments were successfully processed. However, the %r kept the same
value in the calls to restore_command so that the older segments are not
thrown away by pg_restore. I will keep an eye on the slave logs, though,
if its happens again.
>
> (*) I *think* the technical definition is "segment previous to the one
> on which the last restartpoint was set", or something similar.
>
I did a thorough search on this, but to my surprise, the documentation
does not elaborate any further on exactly what a restart point is :-)
Maybe there is somebody who could explain under what conditions a
restart points is created (on the slave) and what could the creation of
a restart point fail?
Duco