On Wed, Sep 10, 2014 at 1:45 AM, Petr Jelinek <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers