Re: Additional current timestamp values

Tom Lane wrote:
> Neil Conway <neilc@samurai.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. +