2000-10-18 19:03:36 -06:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
2001-01-07 14:51:04 +01:00
|
|
|
#shift
|
2007-12-04 12:57:16 +00:00
|
|
|
if [ -n "$BK_USER" ]
|
|
|
|
|
then
|
|
|
|
|
COMMITTER=$BK_USER
|
|
|
|
|
else
|
|
|
|
|
COMMITTER=$USER
|
|
|
|
|
fi
|
2007-12-14 15:43:54 +00:00
|
|
|
FROM=$COMMITTER@mysql.com
|
Fix for BUG#35351 "Maria: R-tree index does not return all expected rows"
BitKeeper/triggers/post-commit:
commits to Maria public list
mysql-test/r/maria-gis-rtree.result:
result is good now, similar to MyISAM's (gis-rtree.result)
storage/maria/ma_rt_index.c:
R-tree key-reading code used info->buff as a cache for the next key read,
but between key read and next key read, there is record read, which
uses info->buff too. In detail, during a SELECT:
First key read: maria_rfirst() is called, which calls maria_rtree_find_first() which calls
maria_rtree_find_req() which comes here
if (after_key < last)
{
// ! the list of keys is copied to info->buff
// and info->buff is remembered in info->int_keypos
info->int_keypos= info->buff;
info->int_maxpos= info->buff + (last - after_key);
memcpy(info->buff, after_key, last - after_key);
info->keyread_buff_used= 0;
}
Then record read:
_ma_read_block_record() (as well as some other functions of
ma_blockrec.c) overwrites info->buff:
if (!(buff= pagecache_read(share->pagecache,
&info->dfile, ma_recordpos_to_page(record_pos), 0,
info->buff, share->page_type,
PAGECACHE_LOCK_LEFT_UNLOCKED, 0)))
So, this has the effect that the keys saved by maria_rtree_find_req() are now lost:
info->int_keypos now contains a copy of a data page!
Then maria_rnext_same() runs (to find second row), calls maria_rtree_find_next() which
does:
if (!info->keyread_buff_used)
{
uchar *key= info->int_keypos;
while (key < info->int_maxpos)
{
if (!maria_rtree_key_cmp(keyinfo->seg,
info->first_mbr_key, key,
info->last_rkey_length, search_flag))
i.e. maria_rtree_key_cmp() is doing comparisons on values it reads from the data page.
Naturally this is bad and no row is found.
Origin of the bug: MARIA_HA::keyread_buff is new in Maria.
Solution: use keyread_buff instead of buff (like _ma_search_next() does),
in R-tree code. Note that ma_blockrec.c functions also use keyread_buff
but they all are write-functions, which should not be running close
to next-key-read. Also note that some ma_rt_index.c functions still
use info->buff, but they are about writes too.
Thanks Monty for the idea.
2008-04-11 11:53:21 +02:00
|
|
|
COMMITS=maria@lists.mysql.com
|
2001-11-07 01:49:38 -06:00
|
|
|
DOCS=docs-commit@mysql.com
|
2001-03-05 10:33:05 +01:00
|
|
|
LIMIT=10000
|
2006-04-11 16:45:10 +03:00
|
|
|
VERSION="maria"
|
2006-09-13 14:15:22 -04:00
|
|
|
BKROOT=`bk root`
|
2000-10-18 20:59:29 -06:00
|
|
|
|
2006-09-14 10:57:00 -04:00
|
|
|
if [ -x /usr/sbin/sendmail ]; then
|
|
|
|
|
SENDMAIL=/usr/sbin/sendmail
|
|
|
|
|
else
|
|
|
|
|
SENDMAIL=sendmail
|
|
|
|
|
fi
|
|
|
|
|
|
2001-04-11 19:38:02 -06:00
|
|
|
if [ "$REAL_EMAIL" = "" ]
|
|
|
|
|
then
|
|
|
|
|
echo "Warning: you must set REAL_EMAIL in your profile"
|
|
|
|
|
else
|
|
|
|
|
FROM=$REAL_EMAIL
|
|
|
|
|
fi
|
|
|
|
|
|
2001-01-14 18:40:26 +02:00
|
|
|
BK_STATUS=$BK_STATUS$BK_COMMIT
|
|
|
|
|
|
2001-01-07 14:51:04 +01:00
|
|
|
if [ "$BK_STATUS" = OK ]
|
2000-10-18 20:59:29 -06:00
|
|
|
then
|
2001-10-15 23:28:30 -05:00
|
|
|
|
2005-02-16 14:03:16 -08:00
|
|
|
HAS_ACTUAL_CHANGES=`bk cset -r+ -d | grep -v "^#"`
|
|
|
|
|
if [ "$HAS_ACTUAL_CHANGES" = "" ]
|
|
|
|
|
then
|
|
|
|
|
echo ChangeSet had no real changes, not sending emails
|
|
|
|
|
exit
|
|
|
|
|
fi
|
|
|
|
|
|
2007-06-13 11:44:58 +02:00
|
|
|
IS_MERGE=`bk changes -r+ -k -m`
|
|
|
|
|
if [ "$IS_MERGE" = "" ]
|
|
|
|
|
then
|
|
|
|
|
echo Merge changeset, not sending mails
|
|
|
|
|
exit
|
|
|
|
|
fi
|
|
|
|
|
|
2003-10-25 22:43:19 +02:00
|
|
|
CHANGESET=`bk -R prs -r+ -h -d':P:::I:' ChangeSet`
|
2005-04-05 15:16:15 +02:00
|
|
|
CSETKEY=`bk -R prs -r+ -h -d':KEY:' ChangeSet`
|
2006-11-12 13:38:13 +02:00
|
|
|
#
|
|
|
|
|
# composing subject lines of commit mails.
|
|
|
|
|
# if a fix targets to a WL and there is a bug referred
|
|
|
|
|
# then X-Bug mail header will contain the first found bug's number
|
|
|
|
|
#
|
|
|
|
|
BUG=`bk -R prs -r+ -h -d':C:' ChangeSet | \
|
|
|
|
|
sed -ne 's/[Bb][Uu][Gg] *# *\([0-9][0-9]*\).*$/BUG#\1/
|
|
|
|
|
s/.*BUG#\([0-9][0-9]*\)/\1/p'`
|
|
|
|
|
WL=`bk -R prs -r+ -h -d':C:' ChangeSet | \
|
|
|
|
|
sed -ne 's/[Ww][Ll] *# *\([0-9][0-9]*\).*$/WL#\1/
|
|
|
|
|
s/.*\(WL#[0-9][0-9]*\)/ \1/p'`
|
2004-03-25 13:29:12 +01:00
|
|
|
if [ "$BUG" = "" ]
|
|
|
|
|
then
|
2007-06-13 11:44:58 +02:00
|
|
|
# TO=dev-public@mysql.com
|
2005-01-25 12:24:50 -08:00
|
|
|
BS=""
|
|
|
|
|
BH=""
|
2004-03-25 13:29:12 +01:00
|
|
|
else
|
2007-06-13 11:44:58 +02:00
|
|
|
# TO=dev-bugs@mysql.com
|
2005-01-25 12:24:50 -08:00
|
|
|
BS=" BUG#$BUG"
|
|
|
|
|
# need newline here
|
|
|
|
|
BH="X-Bug: $BUG
|
|
|
|
|
"
|
2004-03-25 13:29:12 +01:00
|
|
|
fi
|
2001-10-15 23:28:30 -05:00
|
|
|
|
|
|
|
|
#++
|
Fix for BUG#35351 "Maria: R-tree index does not return all expected rows"
BitKeeper/triggers/post-commit:
commits to Maria public list
mysql-test/r/maria-gis-rtree.result:
result is good now, similar to MyISAM's (gis-rtree.result)
storage/maria/ma_rt_index.c:
R-tree key-reading code used info->buff as a cache for the next key read,
but between key read and next key read, there is record read, which
uses info->buff too. In detail, during a SELECT:
First key read: maria_rfirst() is called, which calls maria_rtree_find_first() which calls
maria_rtree_find_req() which comes here
if (after_key < last)
{
// ! the list of keys is copied to info->buff
// and info->buff is remembered in info->int_keypos
info->int_keypos= info->buff;
info->int_maxpos= info->buff + (last - after_key);
memcpy(info->buff, after_key, last - after_key);
info->keyread_buff_used= 0;
}
Then record read:
_ma_read_block_record() (as well as some other functions of
ma_blockrec.c) overwrites info->buff:
if (!(buff= pagecache_read(share->pagecache,
&info->dfile, ma_recordpos_to_page(record_pos), 0,
info->buff, share->page_type,
PAGECACHE_LOCK_LEFT_UNLOCKED, 0)))
So, this has the effect that the keys saved by maria_rtree_find_req() are now lost:
info->int_keypos now contains a copy of a data page!
Then maria_rnext_same() runs (to find second row), calls maria_rtree_find_next() which
does:
if (!info->keyread_buff_used)
{
uchar *key= info->int_keypos;
while (key < info->int_maxpos)
{
if (!maria_rtree_key_cmp(keyinfo->seg,
info->first_mbr_key, key,
info->last_rkey_length, search_flag))
i.e. maria_rtree_key_cmp() is doing comparisons on values it reads from the data page.
Naturally this is bad and no row is found.
Origin of the bug: MARIA_HA::keyread_buff is new in Maria.
Solution: use keyread_buff instead of buff (like _ma_search_next() does),
in R-tree code. Note that ma_blockrec.c functions also use keyread_buff
but they all are write-functions, which should not be running close
to next-key-read. Also note that some ma_rt_index.c functions still
use info->buff, but they are about writes too.
Thanks Monty for the idea.
2008-04-11 11:53:21 +02:00
|
|
|
# maria@ or dev-private@ mail
|
2001-10-15 23:28:30 -05:00
|
|
|
#--
|
2006-09-13 14:15:22 -04:00
|
|
|
|
2007-06-13 19:23:13 +02:00
|
|
|
LIST="commits"
|
Fix for BUG#35351 "Maria: R-tree index does not return all expected rows"
BitKeeper/triggers/post-commit:
commits to Maria public list
mysql-test/r/maria-gis-rtree.result:
result is good now, similar to MyISAM's (gis-rtree.result)
storage/maria/ma_rt_index.c:
R-tree key-reading code used info->buff as a cache for the next key read,
but between key read and next key read, there is record read, which
uses info->buff too. In detail, during a SELECT:
First key read: maria_rfirst() is called, which calls maria_rtree_find_first() which calls
maria_rtree_find_req() which comes here
if (after_key < last)
{
// ! the list of keys is copied to info->buff
// and info->buff is remembered in info->int_keypos
info->int_keypos= info->buff;
info->int_maxpos= info->buff + (last - after_key);
memcpy(info->buff, after_key, last - after_key);
info->keyread_buff_used= 0;
}
Then record read:
_ma_read_block_record() (as well as some other functions of
ma_blockrec.c) overwrites info->buff:
if (!(buff= pagecache_read(share->pagecache,
&info->dfile, ma_recordpos_to_page(record_pos), 0,
info->buff, share->page_type,
PAGECACHE_LOCK_LEFT_UNLOCKED, 0)))
So, this has the effect that the keys saved by maria_rtree_find_req() are now lost:
info->int_keypos now contains a copy of a data page!
Then maria_rnext_same() runs (to find second row), calls maria_rtree_find_next() which
does:
if (!info->keyread_buff_used)
{
uchar *key= info->int_keypos;
while (key < info->int_maxpos)
{
if (!maria_rtree_key_cmp(keyinfo->seg,
info->first_mbr_key, key,
info->last_rkey_length, search_flag))
i.e. maria_rtree_key_cmp() is doing comparisons on values it reads from the data page.
Naturally this is bad and no row is found.
Origin of the bug: MARIA_HA::keyread_buff is new in Maria.
Solution: use keyread_buff instead of buff (like _ma_search_next() does),
in R-tree code. Note that ma_blockrec.c functions also use keyread_buff
but they all are write-functions, which should not be running close
to next-key-read. Also note that some ma_rt_index.c functions still
use info->buff, but they are about writes too.
Thanks Monty for the idea.
2008-04-11 11:53:21 +02:00
|
|
|
TO="maria@lists.mysql.com"
|
2007-06-13 11:44:58 +02:00
|
|
|
if [ -f .tree-is-private ]
|
|
|
|
|
then
|
2007-06-13 19:23:13 +02:00
|
|
|
LIST="dev-private"
|
|
|
|
|
TO="dev-private@mysql.com"
|
2007-06-13 11:44:58 +02:00
|
|
|
fi
|
2001-10-15 23:28:30 -05:00
|
|
|
|
2007-06-13 19:23:13 +02:00
|
|
|
echo "Notifying $LIST list at $TO"
|
2001-06-11 20:26:24 -06:00
|
|
|
(
|
|
|
|
|
cat <<EOF
|
2004-03-25 13:29:12 +01:00
|
|
|
List-ID: <bk.mysql-$VERSION>
|
2001-06-11 20:26:24 -06:00
|
|
|
From: $FROM
|
2007-06-13 19:23:13 +02:00
|
|
|
To: $TO
|
2005-01-25 12:24:50 -08:00
|
|
|
Subject: bk commit into $VERSION tree ($CHANGESET)$BS
|
2005-04-05 15:16:15 +02:00
|
|
|
X-CSetKey: <$CSETKEY>
|
2005-01-25 12:24:50 -08:00
|
|
|
$BH
|
2002-08-15 14:59:14 +10:00
|
|
|
Below is the list of changes that have just been committed into a local
|
2007-12-04 12:57:16 +00:00
|
|
|
$VERSION repository of $COMMITTER. When $COMMITTER does a push these changes
|
|
|
|
|
will be propagated to the main repository and, within 24 hours after the
|
2002-06-17 09:44:39 +10:00
|
|
|
push, to the public repository.
|
2001-06-28 19:48:49 -06:00
|
|
|
For information on how to access the public repository
|
2005-01-25 12:24:50 -08:00
|
|
|
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
|
2000-10-18 20:59:29 -06:00
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
bk changes -v -r+
|
2007-06-18 20:13:33 +02:00
|
|
|
bk rset -r+ -ah | bk gnupatch -h -dup -T
|
WL#3072 Maria recovery:
fix for bug: if a crash happened right after writing a REDO like this:
REDO - UNDO - REDO*, then recovery would ignore the last REDO* (ok),
rollback: REDO - UNDO - REDO* - REDO - CLR, and a next recovery would
thus execute REDO* instead of skipping it again. Recovery now logs
LOGREC_INCOMPLETE_GROUP when it meets REDO* for the first time,
to draw a boundary and ensure it is always skipped. Tested by hand.
Note: ma_test_all fails "maria_chk: error: Key 1 - Found too many records"
not due to this patch (failed before).
BitKeeper/triggers/post-commit:
no truncation of the commit mail, or how to review patches?
mysql-test/include/maria_verify_recovery.inc:
let caller choose the statement used to crash (sometimes we
want the crash to happen at special places)
mysql-test/t/maria-recovery.test:
user of maria_verify_recovery.inc now specifies statement which the
script should use for crashing.
storage/maria/ma_bitmap.c:
it's easier to search for all places using functions from the bitmap
module (like in ma_blockrec.c) if those exported functions all start
with "_ma_bitmap": renaming some of them.
Assertion that when we read a bitmap page, overwriting bitmap->map,
we are not losing information (i.e. bitmap->changed is false).
storage/maria/ma_blockrec.c:
update to new names. Adding code (disabled, protected by a #ifdef)
that I use to test certain crash scenarios (more to come).
storage/maria/ma_blockrec.h:
update to new names
storage/maria/ma_checkpoint.c:
update to new names
storage/maria/ma_extra.c:
update to new names
storage/maria/ma_loghandler.c:
new LOGREC_INCOMPLETE_GROUP
storage/maria/ma_loghandler.h:
new LOGREC_INCOMPLETE_GROUP
storage/maria/ma_recovery.c:
When at the end of the REDO phase we have identified some transactions
with incomplete REDO groups (REDOs without an UNDO or CLR_END),
for each of them we log LOGREC_INCOMPLETE_GROUP. This way, the
upcoming UNDO phase can write more records for such transaction,
a future recovery won't pair the incomplete group with the
CLR_END (as there is LOGREC_INCOMPLETE_GROUP to draw a boundary).
2007-12-10 23:26:53 +01:00
|
|
|
) > $BKROOT/BitKeeper/tmp/commits.txt
|
2006-09-13 14:15:22 -04:00
|
|
|
|
2006-09-14 10:57:00 -04:00
|
|
|
$SENDMAIL -t < $BKROOT/BitKeeper/tmp/commits.txt
|
2001-10-15 23:28:30 -05:00
|
|
|
|
|
|
|
|
#++
|
2001-11-07 01:49:38 -06:00
|
|
|
# docs-commit@ mail
|
2002-05-03 08:57:31 +10:00
|
|
|
# Picks up anything under the Docs subdirectory (relevant for docs team).
|
2001-10-15 23:28:30 -05:00
|
|
|
#--
|
2002-05-03 08:57:31 +10:00
|
|
|
bk changes -v -r+ | grep -q " Docs/"
|
2001-11-08 00:14:16 +01:00
|
|
|
if [ $? -eq 0 ]
|
2001-10-15 23:28:30 -05:00
|
|
|
then
|
|
|
|
|
echo "Notifying docs list at $DOCS"
|
|
|
|
|
(
|
|
|
|
|
cat <<EOF
|
2004-03-25 13:29:12 +01:00
|
|
|
List-ID: <bk.mysql-$VERSION>
|
2001-10-15 23:28:30 -05:00
|
|
|
From: $FROM
|
|
|
|
|
To: $DOCS
|
2005-01-25 12:24:50 -08:00
|
|
|
Subject: bk commit - $VERSION tree (Manual) ($CHANGESET)$BS
|
2001-10-15 23:28:30 -05:00
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
bk changes -v -r+
|
2007-06-18 20:13:33 +02:00
|
|
|
bk rset -r+ -ah | bk gnupatch -h -dup -T
|
2006-09-13 14:15:22 -04:00
|
|
|
) > $BKROOT/BitKeeper/tmp/docs.txt
|
2006-09-14 10:57:00 -04:00
|
|
|
$SENDMAIL -t < $BKROOT/BitKeeper/tmp/docs.txt
|
2001-10-15 23:28:30 -05:00
|
|
|
fi
|
|
|
|
|
|
2000-10-18 20:59:29 -06:00
|
|
|
else
|
2002-08-13 02:33:25 +03:00
|
|
|
echo "commit failed because '$BK_STATUS', you may need to re-clone..."
|
2000-10-18 20:59:29 -06:00
|
|
|
fi
|