Re: recovery_target_time = 'now' is not an error but still impractical setting

From: Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: recovery_target_time = 'now' is not an error but still impractical setting
Date: 2017-08-19 10:04:37
Message-ID: DBXPR03MB3653059BCCC0F27E6E7FBEEF2810@DBXPR03MB365.eurprd03.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-08-18 20:51, Robert Haas wrote:
> On Fri, Aug 18, 2017 at 4:39 AM, Piotr Stefaniak
> <postgres(at)piotr-stefaniak(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message MauMau 2017-08-19 14:29:25 [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?
Previous Message Ildar Musin 2017-08-19 09:21:15 Re: Proposal: global index