From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: now() vs transaction_timestamp() |
Date: | 2018-10-07 04:58:25 |
Message-ID: | CAA4eK1LOQs6mBUHi7dttD_cy3Rq4K7inQR1rhzKv_DGGvYHXVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Oct 6, 2018 at 9:40 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> writes:
> > On 06.10.2018 00:25, Tom Lane wrote:
> >> 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.
>
> > Attached please find very small patch fixing the problem (propagating
> > transaction and statement timestamps to workers).
>
> 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.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-10-07 05:06:39 | Re: now() vs transaction_timestamp() |
Previous Message | Thomas Munro | 2018-10-07 02:30:36 | Re: Relax transactional restrictions on ALTER ENUM ... ADD TYPE (redux) |