to 0 causes wrong (large) length to be read
from the row in _mi_calc_blob_length() when
storing NULL values in (e.g) POINT columns.
This large length is then used to allocate
a block of memory that (on some OSes) causes
trouble.
Fixed by calling the base class's
Field_blob::reset() from Field_geom::reset()
that is called when storing a NULL value into
the column.
mysql-test/r/gis.result:
Bug #27164: test case
mysql-test/t/gis.test:
Bug #27164: test case
sql/field.h:
Bug #27164: not reseting the data pointer
to 0 causes wrong (large) length to be read
from the row in _mi_calc_blob_length() when
storing NULL values in (e.g) POINT columns.
This large length is then used to allocate
a block of memory that (on some OSes) causes
trouble.
fix for cast( AS DATETIME) + 0 operation.
I just implemented Item_datetime_typecast::val() method
as it is usually done in other classes.
Should be fixed more radically in 5.0
mysql-test/r/type_datetime.result:
result added
mysql-test/t/type_datetime.test:
testcase
sql/item_timefunc.h:
added double conversion to Item_datetime_typecast
Shift the ID values up into a range where they will not collide with those
which we use for real data, when we fill the system tables.
Will be merged up to 5.0 where it is needed for 5.0.38.
mysql-test/r/help.result:
Fix the result file according to the changed ID values in "help.test".
mysql-test/t/help.test:
Now that (at least in 5.0) the system tables are filled with real data,
inserting rows vith ID values 1 .. 5 will fail in release build tests (it did in 5.0.38)
like it should already have done in customer installations.
Shift the ID values up into a high area where they will not conflict,
also make the distinct for the different kinds of values (= unique throughout the test).
No change to the logic.
Using a MEMORY table BTREE index for scanning for updatable rows
could lead to an infinite loop.
Everytime a key was inserted into a btree index, the position
in the index scan was cleared. The search started from the
beginning and found the same key again.
Now we do not clear the position on key insert an more.
heap/hp_write.c:
Bug#26996 - Update of a Field in a Memory Table ends with wrong result
Removed the index-scan-breaking nulling of last_pos.
The comment behind this line ("For heap_rnext/heap_rprev")
was misleading. It should have been "Breaks heap_rnext/heap_rprev".
mysql-test/r/heap_btree.result:
Bug#26996 - Update of a Field in a Memory Table ends with wrong result
Added test result.
mysql-test/t/heap_btree.test:
Bug#26996 - Update of a Field in a Memory Table ends with wrong result
Added test.
when index is used
When the table contained TEXT columns with empty contents
('', zero length, but not NULL) _and_ strings starting with
control characters like tabulator or newline, the empty values
were not found in a "records in range" estimate. Hence count(*)
missed these records.
The reason was a different set of search flags used for key
insert and key range estimation.
I decided to fix the set of flags used in range estimation.
Otherwise millions of databases around the world would require
a repair after an upgrade.
The consequence is that the manual must be fixed, which claims
that TEXT columns are compared with "end space padding". This
is true for CHAR/VARCHAR but wrong for TEXT. See also bug 21335.
myisam/mi_range.c:
Bug#26231 - select count(*) on myisam table returns wrong value
when index is used
Added SEARCH_UPDATE to the search flags so that it compares
like write/update/delete operations do. Only so it expects
the keys at the place where they have been inserted.
myisam/mi_search.c:
Bug#26231 - select count(*) on myisam table returns wrong value
when index is used
Added some comments to explain how _mi_get_binary_pack_key()
works.
mysql-test/r/myisam.result:
Bug#26231 - select count(*) on myisam table returns wrong value
when index is used
Added a test.
mysql-test/t/myisam.test:
Bug#26231 - select count(*) on myisam table returns wrong value
when index is used
Added test result.
differences in tables
Certain merge tables were wrongly reported as having incorrect definition:
- Some fields that are 1 byte long (e.g. TINYINT, CHAR(1)), might
be internally casted (in certain cases) to a different type on a
storage engine layer. (affects 4.1 and up)
- If tables in a merge (and a MERGE table itself) had short VARCHAR column (less
than 4 bytes) and at least one (but not all) tables were ALTER'ed (even to an
identical table: ALTER TABLE xxx ENGINE=yyy), table definitions went ouf of
sync. (affects 4.1 only)
This is fixed by relaxing a check for underlying conformance and setting
field type to FIELD_TYPE_STRING in case varchar is shorter than 4
when a table is created.
myisam/mi_create.c:
Added a comment.
mysql-test/r/merge.result:
A test case for bug#26881.
mysql-test/t/merge.test:
A test case for bug#26881.
sql/ha_myisam.cc:
Relaxed some checks performed by check_definition():
As comparing of fulltext keys (and key segments) is not yet implemented,
only return an error in case one of keys is fulltext and other is not.
Otherwise, if both keys are fulltext, accept them as is.
As comparing of spatial keys (and key segments) is not yet implemented,
only return an error in case one of keys is spatial and other is not.
Otherwise, if both keys are spatial, accept them as is.
A workaround to handle situation when field is casted from FIELD_SKIP_ZERO
to FIELD_NORMAL. This could happen only in case field length is 1 and row
format is fixed.
sql/sql_parse.cc:
When a table that has varchar field shorter than 4 is created, field type is
set to FIELD_TYPE_VAR_STRING. Later, when a table is modified using alter
table, field type is changed to FIELD_TYPE_STRING (see Field_string::type).
That means HA_OPTION_PACK_RECORD flag might be lost and thus null_bit might
be shifted by alter table, in other words alter table doesn't create 100%
equal table definition.
This is usually not a problem, since when a table is created/altered,
definition on a storage engine layer is based on one that is passed from
sql layer. But it is a problem for merge engine - null_bit is shifted when
a table (merge or underlying) is altered.
Set field type to FIELD_TYPE_STRING in case FIELD_TYPE_VAR_STRING is shorter
than 4 when a table is created as it is done in Field::type.
incorrect key file for table
In certain cases it could happen that deleting a row could
corrupt an RTREE index.
According to Guttman's algorithm, page underflow is handled
by storing the page in a list for later re-insertion. The
keys from the stored pages have to be inserted into the
remaining pages of the same level of the tree. Hence the
level number is stored in the re-insertion list together
with the page.
In the MySQL RTree implementation the level counts from zero
at the root page, increasing numbers for levels down the tree.
If during re-insertion of the keys the tree height grows, all
level numbers become invalid. The remaining keys will be
inserted at the wrong level.
The fix is to increment the level numbers stored in the
reinsert list after a split of the root block during reinsertion.
myisam/rt_index.c:
Bug#25673 - spatial index corruption, error 126
incorrect key file for table
Added a loop in rtree_delete() to increment the level numbers
stored in the reinsert list after a split of the root block
during reinsertion.
Added comments and DBUG statements.
myisam/rt_key.c:
Bug#25673 - spatial index corruption, error 126
incorrect key file for table
Added DBUG statements.
myisam/rt_split.c:
Bug#25673 - spatial index corruption, error 126
incorrect key file for table
Added DBUG statements.
mysql-test/r/gis-rtree.result:
Bug#25673 - spatial index corruption, error 126
incorrect key file for table
Added the test result.
mysql-test/t/gis-rtree.test:
Bug#25673 - spatial index corruption, error 126
incorrect key file for table
Added a test.
Using INSERT DELAYED on MERGE tables could lead to table
corruptions.
The manual lists a couple of storage engines, which can be
used with INSERT DELAYED. MERGE is not in this list.
The attempt to try it anyway has not been rejected yet.
This bug was not detected earlier as it can work under
special circumstances. Most notable is low concurrency.
To be safe, this patch rejects any attempt to use INSERT
DELAYED on MERGE tables.
mysql-test/r/merge.result:
Bug#26464 - insert delayed + update + merge = corruption
Added test result.
mysql-test/t/merge.test:
Bug#26464 - insert delayed + update + merge = corruption
Added test.
sql/ha_myisammrg.h:
Bug#26464 - insert delayed + update + merge = corruption
Removed HA_CAN_INSERT_DELAYED flag from table_flags().
The insert delayed thread upgrades the lock from the first
entry in MYSQL_LOCK::locks only. Hence it is incapable to
handle MERGE tables, which have as many entries in this
array as they have MyISAM sub-tables.
- Add --debugger=dbx
- Fix --debugger=devenv, --debugger=DevEnv and --debugger=/path/devenv
mysql-test/mysql-test-run.pl:
Add support for --debugger=dbx to mysql-test-run.pl
Fix case senitive match for vc, vcexpress or deven
Make it possible to use full path to debugger for
--debugger=/path/vcexpress
When the ORDER BY clause gets fixed it's allowed to search in the current
item_list in order to find aliased fields and expressions. This is ok for a
SELECT but wrong for an UPDATE statement. If the ORDER BY clause will
contain a non-existing field which is mentioned in the UPDATE set list
then the server will crash due to using of non-existing (0x0) field.
When an Item_field is getting fixed it's allowed to search item list for
aliased expressions and fields only for selects.
sql/sql_base.cc:
Bug#25126: Wrongly resolved field leads to a crash.
When an Item_field is getting fixed it's allowed to search item list for
aliased expressions and fields only for selects.
sql/sql_select.cc:
Bug#25126: Wrongly resolved field leads to a crash.
When an Item_field is getting fixed it's allowed to search item list for
aliased expressions and fields only for selects.
mysql-test/r/update.result:
Added a test case for bug#25126: Wrongly resolved field leads to a crash.
mysql-test/t/update.test:
Added a test case for bug#25126: Wrongly resolved field leads to a crash.
- Build lib/init-db.sql from the output of mysql_create_system_tables
- Remove mysql-test/init_db.sql and mysql-test/lib/init_db.sql
- Leave netware/init_db.sql until 5.0 where we should soon have possibility
to test with mysql-test-run.pl
BitKeeper/deleted/.del-init_db.sql:
Delete: mysql-test/init_db.sql
BitKeeper/deleted/.del-init_db.sql~a77d572c39d5a1f8:
Delete: mysql-test/lib/init_db.sql
BitKeeper/etc/ignore:
Added mysql-test/lib/init_db.sql to the ignore list
mysql-test/Makefile.am:
Build lib/init_db.sql from the output of mysql_create_system_tables
- Add error handling for waitpid returns -1 for "simple run of command"
mysql-test/lib/mtr_process.pl:
- Add error handling for waitpid returns -1
when a simple command is run.
- Add missing return
- Add mtr_errors where the program should never come
- Remove an else to improve program readability
- Change mtr_debug to mtr_warning for "Got EAGAIN from fork()..."
Having maybe_null flag unset for geometry/spatial functions leads to
wrong Item_func_isnull::val_int()'s results.
Fix: set maybe_null flag and add is_null() methods.
mysql-test/r/gis.result:
Fix for bug #26038: X() value of empty NOT NULL POINT is neither NULL nor NOT NULL
- test result.
mysql-test/t/gis.test:
Fix for bug #26038: X() value of empty NOT NULL POINT is neither NULL nor NOT NULL
- test case.
sql/item_geofunc.cc:
Fix for bug #26038: X() value of empty NOT NULL POINT is neither NULL nor NOT NULL
- set maybe_null flag for Item_geometry_func and Item_func_as_wkt.
- moved length check to the beginnig of the
Item_func_spatial_collection::val_str() to affect geometry
collection objects at once.
- changed Item_func_isempty::val_int() and Item_func_issimple::val_int()
to properly handle null_value.
sql/item_geofunc.h:
Fix for bug #26038: X() value of empty NOT NULL POINT is neither NULL nor NOT NULL
- set maybe_null flag for geometry/spatial functions.
- added is_null() to Item_geometry_func and Item_func_spatial_rel
classes.
sql/spatial.cc:
Fix for bug #26038: X() value of empty NOT NULL POINT is neither NULL nor NOT NULL
- changed return type of Geometry::create_from_wkb() to be
consistent with Geometry::create_from_wkt(), now it returns
Geometry object or NULL in case of error.
sql/spatial.h:
Fix for bug #26038: X() value of empty NOT NULL POINT is neither NULL nor NOT NULL
- changed return type of Geometry::create_from_wkb() to be
consistent with Geometry::create_from_wkt(), now it returns
Geometry object or NULL in case of error.
- Starting time of a query sent by file bootstrapping wasn't initialized
and starting time defaulted to 0. This later used value by the Now-
item and is translated to 1970-01-01 11:00:00.
- marking the time with thd->set_time() before the call to
mysql_parse resolves this issue.
mysql-test/r/init_file.result:
Appended test case
mysql-test/std_data/init_file.dat:
Appended test case
mysql-test/t/init_file.test:
Appended test case
mainly occurs on win2003 64bit.
- Execute "exec" commands directly with cmd.exe and replace "--exec echo ..." with "--exec .\echo.exe ..."
client/mysqltest.c:
Workaround the problem with "echo" in windows not behaving like "echo" in Unix.
- Replace "--exec echo ..." with "--exec <path to mysqltest>\echo.exe" thus forcing
use of our own echo implementation which baheves like on Unix.
- The above change makes it possible to remove the need to execute all --exec's
inside cygwin. Add ifdefs to only use use cygwin's bash conditionally
mysql-test/lib/mtr_misc.pl:
Add function for converting to the OS's native format
mysql-test/mysql-test-run.pl:
Convert path to executables to "windows native" (c:\<path>\) instead of "mixed"(c:/<path>) mode
necessary for pipes and redirects to work properly in cmd.exe
client/echo.c:
New BitKeeper file ``client/echo.c''
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint
sql/item.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/sql_select.cc:
Auto merged
ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales.
This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from
being used. Now if 0xff makes an appearance, we find a character not used in the enum and
use that as a separator. If no such character exists, we throw an error.
Any solution would have broken some sort of existing behaviour. This solution should
serve both fractions (those with 0xff and those with ',' in their enums), but
WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/
That is, mysqldump with their current server, and restore when upgrading to one with
this patch.
mysql-test/r/type_enum.result:
Bug#24660: "enum" field type definition problem
Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable
char in some locales), or ',', or both.
mysql-test/t/type_enum.test:
Bug#24660: "enum" field type definition problem
Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable
char in some locales), or ',', or both.
sql/table.cc:
Bug#24660: "enum" field type definition problem
Revert fix for Bug#20922.
sql/unireg.cc:
Bug#24660: "enum" field type definition problem
Use a field-separator for ENUM-values that is not part of those values. If impossible,
throw error.
"update existingtable set anycolumn=nonexisting order by nonexisting" would crash
the server.
Though we would find the reference to a field, that doesn't mean we can then use
it to set some values. It could be a reference to another field. If it is NULL,
don't try to use it to set values in the Item_field and instead return an error.
Over the previous patch, this signals an error at the location of the error, rather
than letting the subsequent deref signal it.
mysql-test/r/order_by.result:
Verify that all permutations work.
mysql-test/t/order_by.test:
Verify that all permutations work.
sql/item.cc:
When the field is NULL, don't dereference it when we set_field().
Instead, raise an error.
The 0000 year is valid.
The ISO standard for "Representation of dates and times" says:
"Calendar years are numbered in ascending order according to the
Gregorian calendar by values in the range [0000] to [9999]."
Reverted fix for 21789: DATETIME with 0000-00-00 11:22:33 should be invalid, but is accepted
as it's not a bug.
Fix for 19370: DateTime datatype in MySQL has two bugs in it
will be reverted during 4.1 -> 5.0 merging as it was pushed to the
5.0 tree.
mysql-test/r/date_formats.result:
Fix for bug #25301: Non-zero dates with year 0000 are invalid
- reverted fix for bug #21789: DATETIME with 0000-00-00 11:22:33 should be invalid, but is accepted
sql-common/my_time.c:
Fix for bug #25301: Non-zero dates with year 0000 are invalid
- reverted fix for bug #21789: DATETIME with 0000-00-00 11:22:33 should be invalid, but is accepted
