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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-10 17:16:19 | Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7 |
Previous Message | Tom Lane | 2009-06-10 16:58:22 | Re: BUG #4849: intermittent future timestamps |