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>
Subject: Re: now() vs transaction_timestamp()
In-reply-to: <9c78b24f-4ec9-e1dd-bdf6-e09e9b5f0e31@postgrespro.ru>
References: <6406dbd2-5d37-4cb6-6eb2-9c44172c7e7c@postgrespro.ru>
 <4268.1538747795@sss.pgh.pa.us> <4911.1538774725@sss.pgh.pa.us>
 <9c78b24f-4ec9-e1dd-bdf6-e09e9b5f0e31@postgrespro.ru>
Comments: In-reply-to Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
	message dated "Sat, 06 Oct 2018 15:51:17 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14824.1538842224.1@sss.pgh.pa.us>
Date: Sat, 06 Oct 2018 12:10:24 -0400
Message-ID: <14825.1538842224@sss.pgh.pa.us>
Precedence: bulk

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