Hi,

Thanks for the reply.
I still work on it, but i guess this problem may on my application side not the 
db server. I mean the appserver connection pool or jdbc configuration. I still 
can not nail it. Because I have another web application with the same iBATIS 
jdbc configuration to the appserver connection pool and connect to the same 
postgres 8.1.6 server, this application runs ok with the current_timestamp.

At this time, I found the time insert into this kind of column is slower than 
the real time and it is closer to the web appserver start time. The start time 
is also the connection pool start time. If I restart the appserver, the next 
row that i insert into the time will update to about the appserver start time. 
It is not looks like a time zone problem.

Thanks.

regards, Steve Yao

-----原始邮件-----
发件人:"Tom Lane" <[EMAIL PROTECTED]>
发送时间:2007-01-17 22:38:51
收件人:"Richard Huxton" <dev@archonet.com>
抄送:[EMAIL PROTECTED],pgsql-general@postgresql.org
主题:Re:&nbsp;[GENERAL]&nbsp;The&nbsp;jdbc&nbsp;and&nbsp;current_timestamp


Richard Huxton <dev@archonet.com> writes:
> The time is fixed at the start of the transaction. This lets you do
> several inserts having the same timestamp.

I think there's another problem here, which is that he's declared
"currenttime" as a timestamp without time zone, but the
CURRENT_TIMESTAMP function yields timestamp with time zone,
meaning there's a TimeZone-dependent conversion going on.  It sounds
to me like there's a difference between the TimeZone setting between
his web app and his psql, leading to an hour's offset, plus a smaller
offset having to do with time-since-transaction-start.

> See here for details of timeofday() etc.
> http://www.postgresql.org/docs/8.2/static/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT

And read the preceding chapter's discussion of the different datetime
data types.

                        regards, tom lane

Reply via email to