Skip site navigation (1) Skip section navigation (2)

Re: Additional current timestamp values

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Additional current timestamp values
Date: 2006-03-20 23:53:20
Message-ID: 200603202353.k2KNrKr14081@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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. +

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-03-21 00:04:40
Subject: Re: Additional current timestamp values
Previous:From: Tom LaneDate: 2006-03-20 23:38:45
Subject: Re: Additional current timestamp values

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-03-20 23:54:13
Subject: Re: Removal of backward-compatibility docs mentions
Previous:From: Tom LaneDate: 2006-03-20 23:38:45
Subject: Re: Additional current timestamp values

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group