Fix for initdb/indexing problems
OK, I have found the problem. I looked AGAIN at CatalogIndexInsert(),
because all problems seem to be localized there. I remembered something
Tom Szybist said yesterday while we were on the phone about Datum only
being one value.
I said they are chained together, which I saw in IndexFormDatum, but
when I looked, I saw that the Datum pointer indexed in IndexFormDatum
was only a single Datum value, not an array of datum values like nulls
is defined.
With single-key system indexes, this was not a problem, but with the new
multi-key system indicies, it is.
I have attached the patch, and it is applied to the tree. Please let me
know if this fixes the many reported index problems. It should.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)Attachments:
/tmp/xtext/plainDownload
Index: src/backend/catalog/indexing.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/catalog/indexing.c,v
retrieving revision 1.29
diff -c -r1.29 indexing.c
*** indexing.c 1998/09/01 16:21:47 1.29
--- indexing.c 1998/09/02 23:00:59
***************
*** 109,120 ****
HeapTuple index_tup;
TupleDesc heapDescriptor;
Form_pg_index index_form;
! Datum datum;
int natts;
AttrNumber *attnumP;
FuncIndexInfo finfo,
*finfoP;
- char nulls[INDEX_MAX_KEYS];
int i;
heapDescriptor = RelationGetDescr(heapRelation);
--- 109,120 ----
HeapTuple index_tup;
TupleDesc heapDescriptor;
Form_pg_index index_form;
! Datum datum[INDEX_MAX_KEYS];
! char nulls[INDEX_MAX_KEYS];
int natts;
AttrNumber *attnumP;
FuncIndexInfo finfo,
*finfoP;
int i;
heapDescriptor = RelationGetDescr(heapRelation);
***************
*** 152,162 ****
(AttrNumber *) index_form->indkey,
heapTuple,
heapDescriptor,
! &datum,
nulls,
finfoP);
! indexRes = index_insert(idescs[i], &datum, nulls,
&heapTuple->t_ctid, heapRelation);
if (indexRes)
pfree(indexRes);
--- 152,162 ----
(AttrNumber *) index_form->indkey,
heapTuple,
heapDescriptor,
! datum,
nulls,
finfoP);
! indexRes = index_insert(idescs[i], datum, nulls,
&heapTuple->t_ctid, heapRelation);
if (indexRes)
pfree(indexRes);
Bruce,
I'm just taking an update from CVS.
I'll kick off the process to build and test before I go to bed
and then check the results in the morning.
It's 1:45am and I've just logged off from work, connected to my
ISP and seen this mail.
I look forward to seeing a clean set of regression results in
a few hours.
Well done Bruce.
Thanks,
Keith.
Bruce Momjian <maillist@candle.pha.pa.us>
Show quoted text
OK, I have found the problem. I looked AGAIN at CatalogIndexInsert(),
because all problems seem to be localized there. I remembered something
Tom Szybist said yesterday while we were on the phone about Datum only
being one value.I said they are chained together, which I saw in IndexFormDatum, but
when I looked, I saw that the Datum pointer indexed in IndexFormDatum
was only a single Datum value, not an array of datum values like nulls
is defined.With single-key system indexes, this was not a problem, but with the new
multi-key system indicies, it is.I have attached the patch, and it is applied to the tree. Please let me
know if this fixes the many reported index problems. It should.
Import Notes
Resolved by subject fallback
Bruce,
Just to confirm, your fixes are just the job.
The regression tests run fine with only the failures I have always
seen due to maths precision and SIGFPE handling.
Thanks for your persistence in tracking this "bug" down.
Keith.
Bruce Momjian <maillist@candle.pha.pa.us>
Show quoted text
OK, I have found the problem. I looked AGAIN at CatalogIndexInsert(),
because all problems seem to be localized there. I remembered something
Tom Szybist said yesterday while we were on the phone about Datum only
being one value.I said they are chained together, which I saw in IndexFormDatum, but
when I looked, I saw that the Datum pointer indexed in IndexFormDatum
was only a single Datum value, not an array of datum values like nulls
is defined.With single-key system indexes, this was not a problem, but with the new
multi-key system indicies, it is.I have attached the patch, and it is applied to the tree. Please let me
know if this fixes the many reported index problems. It should.
Import Notes
Resolved by subject fallback
In message <199809030925.KAA18833@mtcc.demon.co.uk>, Keith Parks writes:
Bruce,
Just to confirm, your fixes are just the job.
The regression tests run fine with only the failures I have always
seen due to maths precision and SIGFPE handling.Thanks for your persistence in tracking this "bug" down.
Keith.
Bruce Momjian <maillist@candle.pha.pa.us>
OK, I have found the problem. I looked AGAIN at CatalogIndexInsert(),
because all problems seem to be localized there. I remembered something
Tom Szybist said yesterday while we were on the phone about Datum only
being one value.I said they are chained together, which I saw in IndexFormDatum, but
when I looked, I saw that the Datum pointer indexed in IndexFormDatum
was only a single Datum value, not an array of datum values like nulls
is defined.With single-key system indexes, this was not a problem, but with the new
multi-key system indicies, it is.I have attached the patch, and it is applied to the tree. Please let me
know if this fixes the many reported index problems. It should.
I just applied this patch to my 08/28 tree. Looks good! I'm seeing a
bunch of other regression test failures, but I think most of these
have been resolved. I compiling a fresh update now. Will report later.
(BTW I'm still in Solaris mode. I'll also take a look at S/Linux).
Thanks!!
Tom Szybist
szybist@boxhill.com