Postgres Pro
Downloads
Home   >   mailing lists

Thread: %r in restore_command?

%r in restore_command?

From
Duco Fijma
Date:
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

Re: %r in restore_command?

From
bernhard_s
Date:
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

Re: %r in restore_command?

From
Alvaro Herrera
Date:
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

Re: %r in restore_command?

From
Duco Fijma
Date:
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