From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alex Hunsaker <badalex(at)gmail(dot)com> |
Cc: | depesz(at)depesz(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Bad interval conversion? |
Date: | 2009-08-18 18:07:24 |
Message-ID: | 26343.1250618844@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alex Hunsaker <badalex(at)gmail(dot)com> writes:
> Ok well we can add overflow checks where we need-em. If you don't
> think the attached patch is horridly ugly- im willing wade through the
> uses of fsec and apply something similar where we need them.
Throwing overflow errors doesn't seem very nice either, especially not
for values that worked just fine before 8.4.
I think the reason fsec_t is declared int32 is that it's expected to
hold only *fractional* seconds, ie, not more than 1 million in the
integer-timestamp world. The code snippets you point at are violating
that assumption. Which is something the float code paths could get away
with, but not so much for integer timestamps. Even if we widened the
type to int64, it'd still mean that the overflow threshold is a factor
of 1e6 closer in these code paths than in other places, and thus that
there would still be values that failed in integer timestamp arithmetic
but not float timestamp arithmetic.
Seems like a proper fix would involve doing some modulo arithmetic to be
sure that we add the integral seconds to the seconds field and only a
fraction to the fsec field.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2009-08-18 19:36:50 | Re: Bad interval conversion? |
Previous Message | Alex Hunsaker | 2009-08-18 17:48:37 | Re: Bad interval conversion? |