Re: Additional current timestamp values

Neil Conway <neilc(at)samurai(dot)com> writes:
> Bruce Momjian wrote:
>> One trick is that these should be the same:
>> test=> SELECT statement_timestamp(), transaction_timestamp();

> Should they be?

ISTM that the most useful definition of "statement_timestamp" is really
"time of arrival of the latest interactive command from the client", and
as such it should not be tied to statement start per se at all.

I'd be in favor of doing gettimeofday() upon receiving a client message,
reporting that value directly for statement_timestamp, and copying it
during transaction start to obtain the value to use for
transaction_timestamp. I don't much like the idea of doing a
gettimeofday() per SQL statement, especially not if that's taken to mean
every SQL statement issued by PL functions (and if it doesn't mean that,
"statement_timestamp" seems like the wrong name). One gettimeofday()
per client message doesn't seem too horrible though, since that's
certainly going to require at least a couple of kernel calls anyway.

Possibly we should call it "command_timestamp" not "statement_timestamp"
to help reduce confusion.

The patch as given strikes me as pretty broken --- it does not advance
statement_timestamp when I would expect (AFAICS it only sets it during
transaction start). I don't like it stylistically either: ISTM either
these things are the responsibility of xact.c or they are the
responsibility of postgres.c, it is not sensible to have both modules
assigning to statement_timestamp.

BTW, now that I look at it, the "statement_timeout" GUC variable seems
to have much of the same confusion about whether "statement" is
equivalent to "interactive command" or not.

regards, tom lane