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-03-31T17:29:24Z
Lists: pgsql-general
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes: > At Thu, 30 Mar 2017 10:57:19 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <2087.1490885839@sss.pgh.pa.us> >> A possible solution is to manually work in wider-than-64-bit >> arithmetic, that is compute the comparison values div and mod >> some pretty-large number and then compare the two halves. >> I seem to recall that we did something similar in a few cases >> years ago, before we were willing to assume that every machine >> had 64-bit integer support. >> >> Of course, for machines having int128, you could just use that >> type directly. I'm not sure how widespread that support is >> nowadays. Maybe a 95%-good-enough solution is to use int128 >> if available and otherwise throw errors for intervals exceeding >> 64 bits. > int128 is seen in numeric.c. It is doable in the same manner. In > that case it will be a bit slower on the platforms without > int128. > By the way is it right that we don't assume this as a bug-fix > which should be done in the Pg10 dev cycle, but an improvement > for 11? Well, it seems like a bug to me. We might conclude that the fix is too risky to back-patch, but it's hard to make that decision before having a patch in hand to evaluate. 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