Re: now() vs transaction_timestamp()

On Sun, Oct 7, 2018 at 10:36 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > On Sat, Oct 6, 2018 at 9:40 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> That's a bit too small ;-) ... one demonstrable problem with it is
> >> that the parallel worker will report the wrong xactStartTimestamp
> >> to pgstat_report_xact_timestamp(), since you aren't jamming the
> >> transmitted value in soon enough. Also, I found that ParallelWorkerMain
> >> executes at least two transactions before it ever gets to the "main"
> >> transaction that does real work, and I didn't much care for the fact
> >> that those were running with worker-local values of xactStartTimestamp
> >> and stmtStartTimestamp. So I rearranged things a bit to ensure that
> >> parallel workers wouldn't generate their own values for either
> >> timestamp, and pushed it.
>
> > Currently, we serialize the other transaction related stuff via
> > PARALLEL_KEY_TRANSACTION_STATE. However, this patch has serialized
> > xact_ts via PARALLEL_KEY_FIXED which appears okay, but I think it
> > would have been easier for future readers of the code if all the
> > similar state variables have been serialized by using the same key.
>
> That state is restored at least two transactions too late.
>

That is right, but I think we can perform shm_toc_lookup for
PARALLEL_KEY_TRANSACTION_STATE at some earlier point and then use the
variables from it to restore the respective state at the different
point of times.

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