Re: now() vs transaction_timestamp() - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: now() vs transaction_timestamp()
Date
Msg-id CAFj8pRB_e81nwbDQ-=MwFkNDqZOukXZNWXVW12ZUVYpuEaPatw@mail.gmail.com
Whole thread Raw
In response to Re: now() vs transaction_timestamp()  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers


so 6. 10. 2018 v 13:47 odesílatel Amit Kapila <amit.kapila16@gmail.com> napsal:
On Sat, Oct 6, 2018 at 2:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> My initial thought was that we should just re-mark transaction_timestamp()
> as parallel-restricted and call it a day, but we'd then have to do the
> same for SQLValueFunction, which is not much fun because it does have
> variants that are parallel safe (and teaching max_parallel_hazard_walker
> which is which seems like a recipe for bugs).
>
> Also, while it might not be quite too late to force a catversion bump
> in v11, this is demonstrably also broken in v10, and we can't do that
> there.
>
> So maybe the right answer is to change the parallel mode infrastructure
> so it transmits xactStartTimestamp, making transaction_timestamp()
> retroactively safe, and then in HEAD only we could re-mark now() as
> safe.  We might as well do the same for statement_timestamp as well.
>

+1.  Sounds like a reasonable way to fix the problem.  I can take care
of it (though not immediately) if you want.


+1

Pavel
 
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: now() vs transaction_timestamp()
Next
From: Konstantin Knizhnik
Date:
Subject: Re: now() vs transaction_timestamp()