Re: now() vs transaction_timestamp()
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Robert Haas <robertmhaas@gmail.com>
Date: 2018-10-06T16:10:24Z
Lists: pgsql-hackers
Konstantin Knizhnik <k.knizhnik@postgrespro.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. regards, tom lane
Commits
-
Propagate xactStartTimestamp and stmtStartTimestamp to parallel workers.
- bdc2e7a19af7 9.6.11 landed
- 58454d0bb07c 10.6 landed
- 3c9dd963cec6 9.5.15 landed
- 6bf278df891d 11.0 landed
- 07ee62ce9e50 12.0 landed