From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
cc: konstantin knizhnik <k.knizhnik@postgrespro.ru>,
        pgsql-hackers <pgsql-hackers@postgresql.org>,
        Robert Haas <robertmhaas@gmail.com>
Subject: Re: now() vs transaction_timestamp()
In-reply-to: 
 <CAA4eK1LTEv+TjHSAD0-7-ZzpxtN2PjR0bu9sWZ_bX53S5D+88Q@mail.gmail.com>
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>
 <14825.1538842224@sss.pgh.pa.us>
 <CAA4eK1LOQs6mBUHi7dttD_cy3Rq4K7inQR1rhzKv_DGGvYHXVQ@mail.gmail.com>
 <31310.1538888799@sss.pgh.pa.us>
 <CAA4eK1LTEv+TjHSAD0-7-ZzpxtN2PjR0bu9sWZ_bX53S5D+88Q@mail.gmail.com>
Comments: In-reply-to Amit Kapila <amit.kapila16@gmail.com>
	message dated "Sun, 07 Oct 2018 10:56:10 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1036.1538892719.1@sss.pgh.pa.us>
Date: Sun, 07 Oct 2018 02:11:59 -0400
Message-ID: <1037.1538892719@sss.pgh.pa.us>
Precedence: bulk

Amit Kapila <amit.kapila16@gmail.com> writes:
> On Sun, Oct 7, 2018 at 10:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

That hardly seems cleaner.

I think this is actually the right way, because
PARALLEL_KEY_TRANSACTION_STATE is (at least by the name) state associated
with the main transaction the worker is going to run.  But given what
I did to xact.c just now, xactStartTimestamp and stmtStartTimestamp are
*not* transaction-local state so far as the worker is concerned.  They
will persist throughout the lifetime of that process, just as the database
ID, user ID, etc, will.  So you might as well argue that none of
FixedParallelState should exist because it should all be in
PARALLEL_KEY_TRANSACTION_STATE, and that doesn't seem like much of
an improvement.

			regards, tom lane