Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4
От
Tom Lane
Тема
Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4
Дата
Msg-id
9485.949034954@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Problem with SELECT on large negative INT4 Nicolas Huillard <nhuillard@ghs.fr>
Re: [GENERAL] Problem with SELECT on large negative INT4 John Brothers <johnbr@mindspring.com>
RE: [GENERAL] Problem with SELECT on large negative INT4 "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 Bruce Momjian <pgman@candle.pha.pa.us>
RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative
INT4 John Brothers <johnbr@mindspring.com>
RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 Tom Lane <tgl@sss.pgh.pa.us>
RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 Bruce Momjian <pgman@candle.pha.pa.us>
Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 Tom Lane <tgl@sss.pgh.pa.us>
Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 Bruce Momjian <pgman@candle.pha.pa.us>
Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 Bruce Momjian <pgman@candle.pha.pa.us>
John Brothers writes: > I don't think that patch will work - Hiroshi whipped up that patch for > me a week ago for a different problem - we have a table with duplicate > primary keys, which seems to be an arithmetic overflow problem because > the index key values can be both very large positive and very large > negative numbers. Actually, if Nicolas' table contains both very large positive and very large negative integers, then his index could be messed up pretty badly. What Hiroshi saw (and I missed :-() was that btint4cmp can fail and return a result of the wrong sign if the difference between two integers overflows. Since index sorting depends critically on the assumption that the comparator always returns consistent results (a < b and b < c must imply a < c, but this can fail if a - c overflows), you could have an out-of-order index. And then probes into the index could fail to find items they should find ... which is exactly the complained-of symptom. Hiroshi neglected to mention that you'd probably need to drop and recreate the index after applying the patch; if it's indeed out of order, just patching the comparator bug isn't enough to fix it. regards, tom lane
В списке pgsql-general по дате отправления
От: Hiroshi Inoue
Дата:
От: Bruce Momjian
Дата: