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;
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. +
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
