On Thu, Aug 17, 2017 at 6:24 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 15 August 2017 at 15:37, Piotr Stefaniak <postg...@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.
We could always use a TRY/CATCH block and add an error in
GetCurrentDateTime and GetCurrentTimeUsec if they are called out of a
transaction context. Rather-safe-than-sorry.
> 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?
"now" is not much interesting, targets in the past are more, like
'yesterday'. This could create back an instance back to the beginning
of the previous day, simplifying scripts creating recovery.conf a bit,
even if that's not much simplification as we are talking about
creating a timestamp string.
> recovery_target_time = 'allballs' sounds fun for recovering corrupted
> databases
This one would not work :)
=# select timestamptz_in('allballs', 0, 0);
ERROR: 22007: invalid input syntax for type timestamp with time zone:
"allballs"
LOCATION: DateTimeParseError, datetime.c:3800
Still that would be fun.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
