Re: [SQL] [GENERAL] CURRENT_TIMESTAMP - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Date
Msg-id 17731.1033708855@sss.pgh.pa.us
Whole thread Raw
In response to Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Oliver Elphick <olly@lfix.co.uk>)
List pgsql-hackers
Oliver Elphick <olly@lfix.co.uk> writes:
> I can see that the current behaviour might give surprising results in a
> long running transaction.  Surprise could be reduced by giving the time
> of first use within the transaction rather than the start of the
> transaction.

[ cogitates ... ]  Hmm, we could do that, and it probably would break
few if any existing apps.  But would it really reduce the surprise
factor?  The complaints we've heard so far all seemed to come from
people who expected multiple current_timestamp calls to show advancing
times within a transaction.

Oliver's idea might be worth doing just on performance grounds: instead
of a gettimeofday() call at the start of every transaction, we'd only
have to reset a flag variable.  When and if current_timestamp is done
inside the transaction, then call the kernel to ask what time it is.
We win on every transaction that does not contain a current_timestamp
call, which is probably a good bet for most apps.  But I don't think
this does much to resolve the behavioral complaints.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Oliver Elphick
Date:
Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Next
From: "Curtis Faith"
Date:
Subject: Re: Advice: Where could I be of help?