Bug #35933 spurious select ERROR 1191 when insert into ... select * is done on fulltext tab
Submitted: 9 Apr 2008 11:03 Modified: 10 Apr 2008 19:06
Reporter: Erik Schoenfelder Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: FULLTEXT search Severity:S3 (Non-critical)
Version:5.0.51a, 5.0 BK OS:Linux (debian, x86, 32bit)
Assigned to: CPU Architecture:Any
Tags: error 1191, fulltext, race condition
Triage: Triaged: D3 (Medium)

[9 Apr 2008 11:03] Erik Schoenfelder
Description:

        copying a table with a fulltext index via

	  insert into ft1 select * from ft2;

	into a identical table sometimes leads to select error 1191
	when concurrent select's are running.

	this happens in an enviroment where the searched table is
	periodically created as a temporary table and finally
	copied into the searched table.

	so the locking time is restricted to copying and the
	searches running parallel are not locked while creating
	the new search table.

	the error 1191 occurs to the search selects after copying, but
	only sometimes not always.
	without running concurrent selects while copying,
	the error seems not to happen.

	the mysql database version is fresh fetched from the server:
	mysql-5.0.51a-linux-i686-glibc23.tar.gz

	but this error could be reproduced with v5.0.45 too.

How to repeat:
        
	script 1:

	create a table with a fulltext indexed column, 
	fill with some data and run selects on this 
	table in a loop.

	in this test the select result is not of interest, 
	only if there is a problem flagged, or a success exit code.

	script t1.sh:
	---------------------------------------------------------------

#!/bin/bash

##
## create table ft1 with one fulltext column:
##
mysql -B test <<EOF
drop table if exists ft1;

CREATE TABLE ft1 (
  data text NOT NULL,
  FULLTEXT KEY data (data)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

EOF

max=1000

##
## fill table with data:
##
i=0
while [ $i -lt $max ] ; do
  i=$(($i + 1))
  echo "insert into ft1 values ('textstring');"
done | mysql -B test 

##
## loop endless selecting data.
##
## on success (regardless if there is a match) print a . on success
## or print the mysql error message.
##
while true ; do
  mysql -B test -e "select match (data) against ('something'), data \
      from ft1 where  match (data) against ('something')" > /dev/null
  if [ $? = 0 ] ; then
      echo -n .
  fi
done

exit 0

	---------------------------------------------------------------

	script 2:

	the second script does the copying forth and back:

	- drop the temp table, create and fill it.

	- lock

	- empty search table and fill from temp table

	- unlock

	running the second script with a parameter sets the count how
	many times this copying should be done.

	script t2.sh:
	---------------------------------------------------------------

#!/bin/bash

if [ "$1" != "" ] ; then 
    loop=$1
else 
    loop=99999
fi

i=0
while [ $i -lt $loop ] ; do
  i=$(($i + 1))

  mysql -B test <<EOF

drop table if exists ft2;
create table ft2 like ft1;
insert into ft2 select * from ft1;

lock table ft1 write, ft2 read;
delete from ft1;
insert into ft1 select * from ft2;
unlock tables;

select count(*) from ft1;

EOF

done

	---------------------------------------------------------------

	testing:

	- run t1.sh

	should start printing dots for every select:

	.............................
	[...]

 	- run t2.sh

	t2 should print the select count(*) output for every loop run:

	count(*)
	1000
	[...]

	- as t2.sh starts, the first script starts to output errors between
	  the successful dots:

	ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
	.......ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
	ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
	.......ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
	[...]

	the spurious behavior can be observed by running the t2.sh copy script
	manyally one copy after an other:

	t2.sh 1
	t2.sh 1
	[...]

	somtimes the output of the t1.sh looping script changes to only
	errors, flagging a broken table:

	ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
	ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
	ERROR 1191 (HY000) at line 1: Can't find FULLTEXT index matching the column list
[...]

	and then continuing with the copies:

	t2.sh 1
	t2.sh 1
	[...]

	the output of the t1.sh looping script changes 
	back to dots, showing the table is usable.

Suggested fix:

	a fix is not known.

 	a usable workaround seems to be adding a repair table quick:

	  insert into ft1 select * from ft2;
	+ repair table ft1 quick;
	  unlock tables;
[9 Apr 2008 11:05] Erik Schoenfelder
test script 1:  t1.sh

Attachment: t1.sh (application/x-sh, text), 745 bytes.

[9 Apr 2008 11:06] Erik Schoenfelder
test script 2:  t2.sh

Attachment: t2.sh (application/x-sh, text), 375 bytes.

[10 Apr 2008 18:48] Sveta Smirnova
Thank you for the report.

I can not repeat described behavior with current development sources, although bug is repeatable with verison 5.0.51a. Please wait next release.
[10 Apr 2008 19:06] Sveta Smirnova
I am sorry: bug is repeatable with last sources too, just needs more time to wait.