Re: Additional current timestamp values

Tom Lane wrote:
> 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 see your point.

> 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

Uh, it does advance:

test=> BEGIN;
BEGIN
test=> SELECT statement_timestamp(), transaction_timestamp();
statement_timestamp | transaction_timestamp
------------------------------+-------------------------------
2006-03-20 18:49:17.88062-05 | 2006-03-20 18:49:11.922934-05
(1 row)

test=> SELECT statement_timestamp(), transaction_timestamp();
statement_timestamp | transaction_timestamp
-------------------------------+-------------------------------
2006-03-20 18:49:19.176823-05 | 2006-03-20 18:49:11.922934-05
(1 row)

start_xact_command() is kind of badly worded. It calls
StartTransactionCommand(), which might or might not start a transaction,
then it does statement_timeout setup. I have always been confused if
statement_timeout times queries inside server-side functions, for
example. I don't think it should.

> 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.

It was done to minimize code change and limit the number of
gettimeofday() calls.

> 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.

True.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +