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

On 2017-08-18 20:51, Robert Haas wrote: > On Fri, Aug 18, 2017 at 4:39 AM, Piotr Stefaniak > 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

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

On Fri, Aug 18, 2017 at 4:39 AM, Piotr Stefaniak 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

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

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

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

On 18 August 2017 at 07:30, Michael Paquier wrote: > On Thu, Aug 17, 2017 at 6:24 PM, Simon Riggs wrote: >> On 15 August 2017 at 15:37, Piotr Stefaniak >> wrote: >> >>> One thing I tried was a combination of

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

On Thu, Aug 17, 2017 at 6:24 PM, Simon Riggs wrote: > On 15 August 2017 at 15:37, Piotr Stefaniak > wrote: > >> One thing I tried was a combination of recovery_target_action = >> 'shutdown' and recovery_target_time = 'now'. The result is

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

On 15 August 2017 at 15:37, Piotr Stefaniak 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

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

On Thu, Aug 17, 2017 at 1:28 PM, Tom Lane wrote: > -1 ... every datatype I/O function is entitled to assume it's being > invoked inside a transaction. I do not think we should break that > on a case-by-case basis. So using timestamptz_in directly in xlog.c > was a bad idea,

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

Michael Paquier writes: > On Tue, Aug 15, 2017 at 11:37 PM, Piotr Stefaniak > wrote: >> At the very least, I think timestamptz_in() should either complain about >> being called outside of transaction or return the expected value, >> because

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

On Tue, Aug 15, 2017 at 11:37 PM, Piotr Stefaniak wrote: > At the very least, I think timestamptz_in() should either complain about > being called outside of transaction or return the expected value, > because returning year 2000 is unuseful at best. I would also like

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

On Tue, Aug 15, 2017 at 10:37 AM, Piotr Stefaniak wrote: > One thing I tried was a combination of recovery_target_action = > 'shutdown' and recovery_target_time = 'now'. The result is surprising, > because then the standby tries to set the target to year 2000. Seems

[HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

First I'll describe my setup just to give you some context. If anyone would like to discuss my ideas or propose their own ideas for discussion, let's do so on -ADMIN or -GENERAL. I have multiple production database clusters which I want to make backups of. Restoring from plain dumps takes too