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

From Tom Lane
Subject Re: now() vs transaction_timestamp()
Date
Msg-id 14825.1538842224@sss.pgh.pa.us
Whole thread Raw
In response to Re: now() vs transaction_timestamp()  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: now() vs transaction_timestamp()  (Amit Kapila <amit.kapila16@gmail.com>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Performance improvements for src/port/snprintf.c
Next
From: Alvaro Herrera
Date:
Subject: Re: Segfault when creating partition with a primary key and sql_droptrigger exists