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

Re: BUG #4849: intermittent future timestamps

From: David Leppik <dleppik(at)vocalabs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4849: intermittent future timestamps
Date: 2009-06-10 17:10:49
Message-ID: C823EB4A-AF68-4E37-8E18-2600922574C8@vocalabs.com (view raw or flat)
Thread:
Lists: pgsql-bugs
Never mind.  Turns out the bug was in our own code (read:  me,  
personally, being stupid) to convert a java.sql.Timestamp to  
java.sql.Date.  Why it works at all in MySQL... I don't even want to  
know.

Why is it we can spend weeks looking at a bug, and we can't find it  
until we decide to blame it on someone else?

David


On Jun 10, 2009, at 11:58 AM, Tom Lane wrote:

> "David Leppik" <dleppik(at)vocalabs(dot)com> writes:
>> We are intermittently getting results from now() which are around  
>> 10 minutes
>> in the future.  Most calls return a reasonable value.  Because the  
>> erroneous
>> timestamps are in the future, they cannot be explained by transaction
>> delays.
>
> Postgres is just reporting what it got from gettimeofday(), so your  
> beef
> is with the kernel (or perhaps with glibc) and/or the hardware you're
> using.  I think I've heard of kernel bugs causing this type of issue.
>
> 			regards, tom lane

--
David Leppik
VP of Software Development
Vocal Laboratories, Inc.
dleppik(at)vocalabs(dot)com





In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-06-10 17:16:19
Subject: Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7
Previous:From: Tom LaneDate: 2009-06-10 16:58:22
Subject: Re: BUG #4849: intermittent future timestamps

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