On Sun, Oct 7, 2018 at 10:36 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Sat, Oct 6, 2018 at 9:40 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> 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. However, this patch has serialized > > xact_ts via PARALLEL_KEY_FIXED which appears okay, but I think it > > would have been easier for future readers of the code if all the > > similar state variables have been serialized by using the same key. > > 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. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
