On Wed, Sep 10, 2014 at 1:45 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:
> Hi,
>
> I recently wanted several times to have slave server prepared at certain
> point in time to reduce the time it takes for it to replay remaining WALs
> (say I have pg_basebackup -x on busy db for example).
In your example, you're thinking to perform the recovery after taking
the backup and stop it at the consistent point (i.e., end of backup) by
using the proposed feature? Then you're expecting that the future recovery
will start from that consistent point and which will reduce the recovery time?
This is true if checkpoint is executed at the end of backup. But there might
be no occurrence of checkpoint during backup. In this case, even future
recovery would need to start from very start of backup. That is, we cannot
reduce the recovery time. So, for your purpose, for example, you might also
need to add new option to pg_basebackup so that checkpoint is executed
at the end of backup if the option is set.
> Currently the way to do it is to have pause_at_recovery_target true
> (default) and wait until pg accepts connection and the shut it down. The
> issue is that this is ugly, and also there is a chance that somebody else
> connects and does bad things (tm) before my process does.
>
> So I wrote simple patch that adds option to shut down the cluster once
> recovery_target is reached. The server will still be able to continue WAL
> replay if needed later or can be configured to start standalone.
What about adding something like action_at_recovery_target=pause|shutdown
instead of increasing the number of parameters?
Regards,
--
Fujii Masao
