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

From Amit Kapila
Subject Re: now() vs transaction_timestamp()
Date
Msg-id CAA4eK1LPVNjf-uU9=qM06ExZW-N2eO6h14ARs8rU6ShTOSRGFw@mail.gmail.com
Whole thread Raw
In response to Re: now() vs transaction_timestamp()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: now() vs transaction_timestamp()  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.

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


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: TAP tests for pg_verify_checksums
Next
From: Pavel Stehule
Date:
Subject: Re: now() vs transaction_timestamp()