Re: now() vs transaction_timestamp()

On Sat, Oct 6, 2018 at 2:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

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