Simon Riggs <[EMAIL PROTECTED]> writes:
> Presumably you don't mean *every* client message, just stmt start ones.
At the moment I've got it setting the statement_timestamp on receipt of
any message that could lead to execution of user-defined code; that
includes Query, Parse, Bind, Execute, FunctionCall. Possibly we could
dispense with the Bind one but I'm unconvinced.
> Can we set that in GetTransactionSnapshot() - that way a serializable
> transaction won't need to update the time after each statement.
No, that's much too late, unless you want to do major rearrangement of
the times at which reporting actions occur. Furthermore the entire
point of statement_timestamp is that it advances for new commands within
the same xact, so your proposal amounts to removing statement_timestamp
entirely.
The actual behavior of CVS tip is that transaction_timestamp copies from
statement_timestamp, not vice versa; that seems fine to me.
> Presumably we have to do at least one at the end when doing statement
> logging?
Only if you've got log_duration on. Per Jim's suggestion, maybe we
could have the <IDLE> activity report advance activity_timestamp only
if log_duration is true, ie, only if it's free to do so.
> I notice there is also one in elog.c for when we have %t set. We
> probably don't need to do both when statement logging.
I'm inclined to think that that one is worth its keep. Sometimes you
really wanna know exactly when a log message was emitted ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
