Re: [HACKERS] Parallel safety of CURRENT_* family

2016-12-13 Thread Robert Haas
On Thu, Dec 1, 2016 at 3:46 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane wrote: >>> ... well, they would be if we passed down xactStartTimestamp to parallel >>> workers, but I can't find any

Re: [HACKERS] Parallel safety of CURRENT_* family

2016-12-01 Thread Tom Lane
I wrote: > Yeah, I didn't have any doubt that it was real. Still don't know > why my test case isn't doing what I expected, though. Doh: the planner knows that transaction_timestamp() is stable, so it concludes that the DISTINCT condition is vacuous. There is a "Unique" node in the plan, but it

Re: [HACKERS] Parallel safety of CURRENT_* family

2016-12-01 Thread Tom Lane
Robert Haas writes: > On Thu, Dec 1, 2016 at 3:46 PM, Tom Lane wrote: >> but it doesn't: >> >> regression=# select distinct transaction_timestamp() from tenk1; >> transaction_timestamp >> --- >> 2016-12-01 15:44:12.839417-05

Re: [HACKERS] Parallel safety of CURRENT_* family

2016-12-01 Thread Robert Haas
On Thu, Dec 1, 2016 at 3:46 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane wrote: >>> ... well, they would be if we passed down xactStartTimestamp to parallel >>> workers, but I can't find any

Re: [HACKERS] Parallel safety of CURRENT_* family

2016-12-01 Thread Tom Lane
Robert Haas writes: > On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane wrote: >> ... well, they would be if we passed down xactStartTimestamp to parallel >> workers, but I can't find any code that does that. In view of the fact that >> transaction_timestamp()

Re: [HACKERS] Parallel safety of CURRENT_* family

2016-12-01 Thread Robert Haas
On Thu, Dec 1, 2016 at 2:32 PM, Tom Lane wrote: > I wrote: >> <5bih4k+4jfl6m39j...@guerrillamail.com> writes: >>> pg_proc shows that now() is marked as restricted, but >>> transaction_timestamp() is marked as safe. > >> That's certainly silly, because they're equivalent. I

Re: [HACKERS] Parallel safety of CURRENT_* family

2016-12-01 Thread Tom Lane
I wrote: > <5bih4k+4jfl6m39j...@guerrillamail.com> writes: >> pg_proc shows that now() is marked as restricted, but >> transaction_timestamp() is marked as safe. > That's certainly silly, because they're equivalent. I should think > they're both safe. Robert? ... well, they would be if we

Re: [HACKERS] Parallel safety of CURRENT_* family

2016-12-01 Thread Tom Lane
<5bih4k+4jfl6m39j...@guerrillamail.com> writes: > How should I mark a function which calls CURRENT_DATE? Parallel safe or > parallel restricted? > pg_proc shows that now() is marked as restricted, but transaction_timestamp() > is marked as safe. That's certainly silly, because they're

[HACKERS] Parallel safety of CURRENT_* family

2016-12-01 Thread 5bih4k+4jfl6m39j23k
Hello How should I mark a function which calls CURRENT_DATE? Parallel safe or parallel restricted? pg_proc shows that now() is marked as restricted, but transaction_timestamp() is marked as safe. The manual (https://www.postgresql.org/docs/9.6/static/functions-datetime.html) says that "now()