On Wed, 2014-05-07 at 01:00 -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > It looks like timestamp[tz]_pl_interval() is not doing proper validation
> > in all paths.
>
> > Patch attached. I looked for other areas that might be affected, but
> > none jumped out.
>
> This seems to be adding a heck of a lot of cycles (viz, replacing a
> simple int64 or float8 addition with timestamp2tm then tm2timestamp)
> to fix a corner case that will probably not matter to anyone anytime
> in the next 200 thousand years, give or take a few millenia. I'm okay
> with the concept of detecting overflow here, but not at this price.
> Can't we do a more direct overflow check, comparable to what ordinary
> int64/float8 addition does?
It's a bit more complex than that, because a similar example of the bug
occurs without overflow when float timestamps are enabled. In
timestamp2tm(), the date can end up larger than INT_MAX.
In principle, I think the check in timestamp_pl_interval() can be quite
cheap, because we essentially just need to check for overflow and do a
bounds check. But it's hard to determine the precise valid bounds, and
it seems a little fragile.
I will see if I can extract the important parts of the validity check
into a new function (or macro). It would need to match the other checks
precisely though, otherwise this bug will persist.
> Also, surely timestamp_mi_interval has got the identical issue, and
> probably some other operators.
timestamp_mi_interval() calls timestamp_pl_interval(). I'll take a look
around for other similar problems though.
Regards,
Jeff Davis
