BUG#18036 - update of table joined to self reports table as crashed
Set exclude_from_table_unique_test value back to FALSE. It is needed for
further check in multi_update::prepare whether to use record cache.
tables
Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a
temporary table to store the results of SELECT ... LIMIT .. and then
uses that table as a source for INSERT. The problem is that in some cases
it actually skips the LIMIT clause in doing that and materializes the
whole SELECT result set regardless of the LIMIT.
This fix is limiting the process of filling up the temp table with only
that much rows that will be actually used by propagating the LIMIT value.
Certain updates of table joined to self results in unexpected
behavior.
The problem was that record cache was mistakenly enabled for
self-joined table updates. Normally record cache must be disabled
for such updates.
Fixed wrong condition in code that determines whether to use
record cache for self-joined table updates.
Only MyISAM tables were affected.
Fix for bug#16716 for --ps-protocol mode.
item_cmpfunc.cc:
Fix for a memory allocation/freeing problem in agg_cmp_type() after fix
for bug#16377. Few language corrections.
INSERT triggers".
In cases when REPLACE was internally executed via update and table had
on update (on delete) triggers defined we exposed the fact that such
optimization used by callng on update (not calling on delete) triggers.
Such behavior contradicts our documentation which describes REPLACE as
INSERT with optional DELETE.
This fix just disables this optimization for tables with on delete triggers.
The optimization is still applied for tables which have on update but have
no on delete triggers, we just don't invoke on update triggers in this case
and thus don't expose information about optimization to user.
Also added test coverage for values returned by ROW_COUNT() function (and
thus for values returned by mysql_affected_rows()) for various forms of
INSERT.
The intermediate (not temporary) files of the new table
during ALTER TABLE was visible for SHOW TABLES. These
intermediate files are copies of the original table with
the changes done by ALTER TABLE. After all the data is
copied over from the original table, these files are renamed
to the original tables file names. So they are not temporary
files. They persist after ALTER TABLE, but just with another
name.
Normal GRANT checking takes place for the intermediate table.
Everyone who can see the original table (and hence the final
table) can also see the intermediate table. But noone else.
In 5.0 the intermediate files are invisible for SHOW TABLES
because all file names beginning with "#sql" were suppressed.
In 5.1 temporary files are created in TMPDIR, so that they
don't appear in the database directories. Also in 5.1 a
translation between table names and file names is done. The
tmp_file_prefix on file level is now "@0023sql".
The suppression of files starting with tmp_file_prefix is
still in place, but still only files beginning with "#sql"
were suppressed.
I do now translate tmp_file_prefix from table name to file
name before comparing it with the files in a directory.
This suppresses the intermediate files again.
No test case. The test case looks so that a reasonable big
table is altered while a second thread runs SHOW TABLES.
This in itself would be possible to do, but on slow machines
it would add too much time to the test suite, while on fast
machines the ALTER TABLE might have finished before SHOW
TABLES looks at the directory. Even if there might be a good
balance for todays machines, one day the test would become
void as the intermediate table would not be seen even with
the bug in place. I added a test script to the bug report.
It can easily be changed so that it uses a table size that
is appropriate for the test machine.
