Re: [HACKERS] INTERVAL overflow detection is terribly broken

2014-01-30 Thread Bruce Momjian
On Mon, Jan 27, 2014 at 10:48:16PM -0500, Bruce Momjian wrote: > On Mon, Jan 27, 2014 at 07:19:21PM -0500, Tom Lane wrote: > > Bruce Momjian writes: > > > Oh, one odd thing about this patch. I found I needed to use INT64_MAX, > > > but I don't see it used anywhere else in our codebase. Is this O

Re: [HACKERS] INTERVAL overflow detection is terribly broken

2014-01-27 Thread Bruce Momjian
On Mon, Jan 27, 2014 at 07:19:21PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > Oh, one odd thing about this patch. I found I needed to use INT64_MAX, > > but I don't see it used anywhere else in our codebase. Is this OK? Is > > there a better way? > > Most of the overflow tests in int.c

Re: [HACKERS] INTERVAL overflow detection is terribly broken

2014-01-27 Thread Tom Lane
Bruce Momjian writes: > Oh, one odd thing about this patch. I found I needed to use INT64_MAX, > but I don't see it used anywhere else in our codebase. Is this OK? Is > there a better way? Most of the overflow tests in int.c and int8.c are coded to avoid relying on the MIN or MAX constants; wh

Re: [HACKERS] INTERVAL overflow detection is terribly broken

2014-01-27 Thread Bruce Momjian
On Mon, Jan 27, 2014 at 04:47:22PM -0500, Bruce Momjian wrote: > The updated attached patch has overflow detection for interval > subtraction, multiply, and negate. There are also some comparison > cleanups. Oh, one odd thing about this patch. I found I needed to use INT64_MAX, but I don't see i

Re: [HACKERS] INTERVAL overflow detection is terribly broken

2014-01-27 Thread Bruce Momjian
On Sun, Jan 26, 2014 at 02:13:03PM +0100, Florian Pflug wrote: > On Jan26, 2014, at 03:50 , Bruce Momjian wrote: > > Patch attached. > > > + if ((float)tm->tm_year * MONTHS_PER_YEAR + tm->tm_mon > INT_MAX) > > + return -1; > > Is this bullet-proof? If float and int are both 32-bit, t

Re: [HACKERS] INTERVAL overflow detection is terribly broken

2014-01-26 Thread Florian Pflug
On Jan26, 2014, at 03:50 , Bruce Momjian wrote: > Patch attached. > + if ((float)tm->tm_year * MONTHS_PER_YEAR + tm->tm_mon > INT_MAX) > + return -1; Is this bullet-proof? If float and int are both 32-bit, the float's mantissa will be less than 32-bit (24 or so, I think), and thu

Re: [HACKERS] INTERVAL overflow detection is terribly broken

2014-01-25 Thread Bruce Momjian
On Sun, Jun 23, 2013 at 03:00:59PM +0200, Rok Kralj wrote: > Hi, after studying ITERVAL and having a long chat with RhoidumToad and > StuckMojo on #postgresql, I am presenting you 3 bugs regarding INTERVAL. OK, I am going to merge this with the previous report/patch which fixes: SELECT IN

Re: [HACKERS] INTERVAL overflow detection is terribly broken

2013-06-25 Thread Rok Kralj
So, any insights on these problems? They might not be critical, but might be silently corrupting someone's data. 2013/6/23 Rok Kralj > Hi, after studying ITERVAL and having a long chat with RhoidumToad and > StuckMojo on #postgresql, I am presenting you 3 bugs regarding INTERVAL. > > As far as

[HACKERS] INTERVAL overflow detection is terribly broken

2013-06-23 Thread Rok Kralj
Hi, after studying ITERVAL and having a long chat with RhoidumToad and StuckMojo on #postgresql, I am presenting you 3 bugs regarding INTERVAL. As far as I understand, the Interval struct (binary internal representation) consists of: int32 months int32 days int64 microseconds 1. OUTPUT ERRORS: S