Re: now() vs transaction_timestamp()

so 6. 10. 2018 v 13:47 odesílatel Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
napsal:

> 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.
>
>
+1

Pavel

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