so 6. 10. 2018 v 13:47 odesÃlatel Amit Kapila <amit.kapil...@gmail.com> napsal:
> On Sat, Oct 6, 2018 at 2:55 AM Tom Lane <t...@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 > >