On Sun, Oct 7, 2018 at 11:12 AM Konstantin Knizhnik
<k.knizhnik@postgrespro.ru> wrote:
>
> On 07.10.2018 07:58, Amit Kapila wrote:
> > On Sat, Oct 6, 2018 at 9:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> 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.
> >>
> > Currently, we serialize the other transaction related stuff via
> > PARALLEL_KEY_TRANSACTION_STATE.
> Yes, it was my first though to add serialization of timestamps to
> SerializeTransactionState.
> But it performs serialization into array of TransactionId, which is
> 32-bit (except PGProEE), and so too small for TimestampTz.
Right, it seems using another format to add timestampTz in that
serialization routine might turn out to be more invasive especially
considering that we have to back-patch this fix.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
