From: Lars-Erik Bjørk Date: July 15 2009 9:34am Subject: Re: Gold Star for Lars List-Archive: http://lists.mysql.com/falcon/794 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; delsp=yes; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Jul 14, 2009, at 9:13 PM, Jim Starkey wrote: > A gold star for Lars! > Thanks! :) > > Lars-Erik Bj=F8rk wrote: >> Hi all, >> >> I have looked at bug#46083 (falcon_pagesize2K fails in =20 >> IndexRootPage::addIndexEntry() during recovery) today, and I have = =20 >> debugged the relevant parts using the log and tablespace files = =20 >> provided by Olav. >> >> This is what seems to happen: >> >> We try to add a node in IndexRootPage::addIndexEntry. Here is a = =20 >> piece of the code: >> >> >> >> /* If the node fits on page, we're done */ >> >> AddNodeResult result; >> >> for (;;) >> { >> result =3D page->addNode(dbb, key, recordNumber); >> >> >> The node does not fit on the page, and we are told to split the = =20 >> page at the middle. >> >> In IndexPage::splitIndexPageMiddle, we search for a node to split = =20 >> on. We want to chose a node >> where the prefix compression is poor. >> >> >> for (; node.node < pageEnd; node.getNext(bucketEnd)) >> { >> //int l =3D >> node.expandKey(key); >> >> if (node.offset || node.length) >> { >> if (node.nextNode > midpoint) >> break; >> >> chain =3D node.node; >> } >> >> } >> >> >> >> Then we check to make sure that this is not the last node on the = =20 >> page, and if it is, we split on the previous node (prevNode) >> (I sent a mail about the calculation of the previous node some = =20 >> weeks ago, unrelated to this): >> >> // The split node should never be the last node on the page >> if ((UCHAR*) node.nextNode > (UCHAR*) this + length) >> node =3D prevNode; >> >> What I see in the debugger is that (UCHAR*) node.nextNode =3D=3D = =20 >> (UCHAR*) this + length (note *equal*). To my understanding, this = =20 >> *is* the last node on the page, and the condition should have been= =20 >> '>=3D' instead of just '>'. This means that we in this case split = on =20 >> the last node instead of the second to last node. On the next = =20 >> iteration we will navigate to this page once again, and try to = =20 >> insert into it. This page is still full (same length as the last = =20 >> time, we split on the END_BUCKET node I assume), and we will split= =20 >> it again. This goes on ... and on (I have looped through 14 of the= =20 >> iterations). >> >> If I change this condition from '>' to '>=3D' and also actually = =20 >> update prevNode in the loop showed earlier, so that it does not = =20 >> refer to the first node on the page, the node will be inserted on = =20 >> the second iteration, after the first split. The recovery still = =20 >> segfaults, but on a different place that I have no knowledge of, = =20 >> further down the recovery process :) >> >> Does this sound like a plausible theory? >> >> /Lars-Erik >> >> >> >> > > > --=20 > Jim Starkey > President, NimbusDB, Inc. > 978 526-1376 > > > --=20 > Falcon Storage Engine Mailing List > For list archives: http://lists.mysql.com/falcon > To unsubscribe: http://lists.mysql.com/falcon?unsub=3Dlars-erik.= bjork@stripped >