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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
