On 2017-08-18 20:51, Robert Haas wrote: > On Fri, Aug 18, 2017 at 4:39 AM, Piotr Stefaniak > <postg...@piotr-stefaniak.me> wrote: >> On 2017-08-17 11:24, Simon Riggs wrote: >>> Your suggestion of "furthest" is already the default behaviour. >>> >>> Why are you using 'now'? Why would you want to pick a randomly >>> selected end time? >> >> The idea in both cases was to stop the recovery in order to prevent the >> standby from selecting new timeline. I want to be able to continue the >> recovery from future WAL files. "Furthest" really meant "as far as >> possible without completing recovery". > > Can you use recovery_target_action='shutdown' instead?
The thing I've tried was a combination of recovery_target_action = 'shutdown' and recovery_target_time = 'now'. Do you mean recovery_target_action = 'shutdown' and everything else unset (default)? That leads to the standby selecting new timeline anyway. Adding standby_mode = on prevents that, but then there is no shutdown. Am I missing something? The only way I've managed to get recovery_target_action = 'shutdown' to work as I needed was to follow advice by Matthijs and Christoph to combine recovery_target_action with either setting recovery_target_time to "now" spelled in the usual, non-special way or setting recovery_target_xid to the latest transaction ID pg_xlogdump could find. You could also try recovery_target_lsn, but I don't have that in 9.4. I don't like that line of thought though, so for now I'll use the restore_command hack I mentioned in the first message of this thread. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers