Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> 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;
        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.


  Bruce Momjian
  SRA OSS, Inc.

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to