Re: Unexpected interval comparison
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: adrian.klaver@aklaver.com, frazer@frazermclean.co.uk,
pgsql-general@postgresql.org
Date: 2017-04-04T22:06:38Z
Lists: pgsql-general
Attachments
- testit-fail.c (text/x-c)
- testit-ok.c (text/x-c)
- (unnamed) (text/plain)
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes: > The first attached is the revised patch and the second is > temporary sanity check code for non-128bit environment code. (but > works only on 128 bit environment) This seemed to me to be probably even less correct, so I extracted the addition and multiplication logic into a standalone test program (attached), which compares the result of a multiplication to that of native int128 arithmetic. I changed the order of the LinearInterval fields to be LS-first so that I could overlay them onto an int128 result (on a little-endian machine); this is just for testing purposes not something we must do in the finished code. I soon found cases where it indeed fails, eg $ ./a.out 0x7ffffffff 0x7ffffffff 7FFFFFFFF * 7FFFFFFFF result = 62 18446744004990074881 result = 3E FFFFFFF000000001 MISMATCH! result = 63 18446744004990074881 result = 3F FFFFFFF000000001 After fooling with it for awhile, I decided that the cause of the problems was basically not thinking carefully about the lower half of the value being unsigned: that affects when to do carries in the addition macro, and we also have to be careful about whether or not to sign-extend the partial product terms. The second attached file is a version that I can't break anymore, though I'm not quite sure it's bug-free. regards, tom lane
Commits
-
Fix integer-overflow problems in interval comparison.
- fd52b8834330 9.6.3 landed
- d68a2b20ae2c 9.5.7 landed
- 8851bcf8813b 9.4.12 landed
- df1a699e5ba3 10.0 landed