| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me> |
| Cc: | 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-17 09:24:23 |
| Message-ID: | CANP8+jJRUdNDe4wArkjqEb2QpSk5MdFXJdBRCN_mf-EGdkgKwA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 15 August 2017 at 15:37, Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oliver Ford | 2017-08-17 09:48:33 | Re: Fix number skipping in to_number |
| Previous Message | Dilip Kumar | 2017-08-17 09:15:46 | Re: why not parallel seq scan for slow functions |