Postgres Pro
Downloads
Home   >   mailing lists

Re: [HACKERS] recovery_target_time = 'now' is not an error but stillimpractical setting - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [HACKERS] recovery_target_time = 'now' is not an error but stillimpractical setting
Date
Msg-id CANP8+jJRUdNDe4wArkjqEb2QpSk5MdFXJdBRCN_mf-EGdkgKwA@mail.gmail.com
Whole thread Raw
In response to [HACKERS] recovery_target_time = 'now' is not an error but still impracticalsetting  (Piotr Stefaniak <postgres@piotr-stefaniak.me>)
Responses Re: [HACKERS] recovery_target_time = 'now' is not an error but stillimpractical setting  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] recovery_target_time = 'now' is not an error but stillimpractical setting  (Piotr Stefaniak <postgres@piotr-stefaniak.me>)
List pgsql-hackers
Tree view 
On 15 August 2017 at 15:37, Piotr Stefaniak <postgres@piotr-stefaniak.me> wrote:

> One thing I tried was a combination of recovery_target_action =
> 'shutdown' and recovery_target_time = 'now'. The result is surprising

Indeed, special timestamp values were never considered in the design,
so I'm not surprised they don't work and have never been tested.

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?

recovery_target_time = 'allballs' sounds fun for recovering corrupted databases

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] why not parallel seq scan for slow functions
Next
From: Oliver Ford
Date:
Subject: Re: [HACKERS] Fix number skipping in to_number