On 07.10.2018 07:58, Amit Kapila wrote:
On Sat, Oct 6, 2018 at 9:40 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
Konstantin Knizhnik <k.knizh...@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. Certainly it
is possible to store timestamp into pair of words, but frankly speaking
I do not like approach used in SerializeTransactionState: IMHO
serializer should either produce stream of bytes, either use some structure.
Serialization to array of words combines drawbacks of both approaches.
Also using type TransactionId for something very different from XIDs
seems to be not so good idea.
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.
