Обсуждение: %r in restore_command?
Hi, 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. Thanks, Duco
Hi Duco, sorry that I can't help you. But I want to say, that I have experienced this last week too. In my case there was a power outage before and after restart this happened, so ... ... but would be nice to have a comment from an expert. Regards, Bernhard
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? (*) I *think* the technical definition is "segment previous to the one on which the last restartpoint was set", or something similar. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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