Re: [HACKERS] recovery_target_time = 'now' is not an error but stillimpractical setting
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] recovery_target_time = 'now' is not an error but stillimpractical setting |
Дата | |
Msg-id | CAB7nPqQ7GMiCPgGH=9d1FuDTr9pY=sC45unrQoz=31+X_hXPwg@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] recovery_target_time = 'now' is not an error but still impracticalsetting (Piotr Stefaniak <postgres@piotr-stefaniak.me>) |
Ответы |
Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting
|
Список | pgsql-hackers |
On Tue, Aug 15, 2017 at 11:37 PM, Piotr Stefaniak <postgres@piotr-stefaniak.me> 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 to > become able to do what I'm doing in a less hacky way (assuming there > isn't one already but I may be wrong), perhaps once there is a new > 'furthest' setting for recovery_target or when recovery_target_time = > 'now' works as I expected. Hm. I think that the most simple solution here would be to change GetCurrentDateTime() and GetCurrentTimeUsec() so as they use GetCurrentTimestamp() instead of the transaction-level equivalents if those code paths are invoked outside of a transaction. Any code using those routines would get stupid timestamps anyway if they try to use keywords like 'today', 'now' or 'tomorrow' so that does not sound like a bad change to me. And yes, that's clearly a bug. Nice discovery. -- Michael
В списке pgsql-hackers по дате отправления: