RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4
От | Nicolas Huillard |
---|---|
Тема | RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 |
Дата | |
Msg-id | 01BF69E0.DA513890@agen.int.ghs обсуждение исходный текст |
Список | pgsql-sql |
Thank to everybody, I recompiled Postgres and tested it on the same DB : the offending SELECT worked, without any index regeneration.Maybe the order in which the items where inserted in the table (using COPY, before creating the index) madeit working. I only had problems with the source RPMs : I installed it (6.5.2), added a patch file for this, recompiled, but wasn't ableto get brand new RPM package for installing on my other machines... What I did for testing my compilation with the fresh "postgres" binary, is installing it in /usr/bin, in place of the otherone. Is it the only think to do, or will there be side effects if I don't install more binaries ? Maybe Lamar Owen could help me getting a fresh patched RPM ? Nicolas Huillard -----Message d'origine----- De: Tom Lane [SMTP:tgl@sss.pgh.pa.us] Date: vendredi 28 janvier 2000 05:49 À: John Brothers Cc: pgsql-general@hub.org; pgsql-sql@hub.org Objet: Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 John Brothers <johnbr@mindspring.com> 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-sql по дате отправления: