Skip site navigation (1) Skip section navigation (2)

RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4

From: Nicolas Huillard <nhuillard(at)ghs(dot)fr>
To: "pgsql-general(at)hub(dot)org" <pgsql-general(at)hub(dot)org>, "pgsql-sql(at)hub(dot)org" <pgsql-sql(at)hub(dot)org>
Subject: RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4
Date: 2000-01-28 21:41:43
Message-ID: 01BF69E0.DA513890@agen.int.ghs (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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) made it 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 able to 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 other one. 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(at)sss(dot)pgh(dot)pa(dot)us]
Date:	vendredi 28 janvier 2000 05:49
À:	John Brothers
Cc:	pgsql-general(at)hub(dot)org; pgsql-sql(at)hub(dot)org
Objet:	Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4 

John Brothers <johnbr(at)mindspring(dot)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 by date

Next:From: Nicolas HuillardDate: 2000-01-28 22:31:34
Subject: RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4
Previous:From: Bruce MomjianDate: 2000-01-28 17:19:38
Subject: Re: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4

pgsql-general by date

Next:From: Nicolas HuillardDate: 2000-01-28 22:31:34
Subject: RE: [SQL] RE: [GENERAL] Problem with SELECT on large negative INT4
Previous:From: Ross J. ReedstromDate: 2000-01-28 19:59:54
Subject: Re: [GENERAL] How to handle non-postgres questions?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group