An error occurred fetching the project authors.
- 23 Feb, 2007 4 commits
-
-
anozdrin/alik@alik.opbmk authored
'shutdown_delay' option name.
-
anozdrin/alik@alik.opbmk authored
-
anozdrin/alik@alik.opbmk authored
which accidentally got broken during the merge on 16-Feb-2007.
-
anozdrin/alik@alik.opbmk authored
Fix timeouts. Only test suite is changed.
-
- 20 Feb, 2007 1 commit
-
-
anozdrin/alik@alik.opbmk authored
The cause of im_daemon_life_cycle.imtest random failures was the following behaviour of some implementations of LINUX threads: let's suppose that a process has several threads (in LINUX threads, there is a separate process for each thread). When the main process gets killed, the parent receives SIGCHLD before all threads (child processes) die. In other words, the parent receives SIGCHLD, when its child is not completely dead. In terms of IM, that means that IM-angel receives SIGCHLD when IM-main is not dead and still holds some resources. After receiving SIGCHLD, IM-angel restarts IM-main, but IM-main failed to initialize, because previous instance (copy) of IM-main still holds server socket (TCP-port). Another problem here was that IM-angel restarted IM-main only if it was killed by signal. If it exited with error, IM-angel thought it's intended / graceful shutdown and exited itself. So, when the second instance of IM-main failed to initialize, IM-angel thought it's intended shutdown and quit. The fix is 1. to change IM-angel so that it restarts IM-main if it exited with error code; 2. to change IM-main so that it returns proper exit code in case of failure.
-
- 19 Feb, 2007 4 commits
-
-
thek@kpdesk.mysql.com authored
into kpdesk.mysql.com:/home/thek/dev/mysql-5.0-runtime
-
thek@kpdesk.mysql.com authored
- Starting time of a query sent by bootstrapping wasn't initialized and starting time defaulted to 0. This later used value by NOW- item and was translated to 1970-01-01 11:00:00. - Marketing the time with thd->set_time() before the call to mysql_parse resolves this issue. - set_time was refactored to be part of the thd->init_for_queries- process.
-
thek@kpdesk.mysql.com authored
into kpdesk.mysql.com:/home/thek/dev/bug23240/my50-bug23240
-
thek@kpdesk.mysql.com authored
- 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.
-
- 16 Feb, 2007 2 commits
-
-
malff/marcsql@weblab.(none) authored
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
-
- 14 Feb, 2007 1 commit
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
-
- 13 Feb, 2007 7 commits
-
-
igor@olga.mysql.com authored
-
ibabaev@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.0-opt
-
cmiller@zippy.cornsilk.net authored
Showstopper and regression against 5.0.24. Previously, we ignored seek() errors (see Bug#22828) and let seek()s against pipes fail. Now, since we check that a seek didn't fail, and return without reading, this bug popped up. This restores the behavior for file-ish objects that could never be seek()ed.
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26209
-
- 12 Feb, 2007 17 commits
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/25492/my50-25492
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/25492/my50-25492
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/25492/my50-25492
-
malff/marcsql@weblab.(none) authored
operations) Before this change, the boolean predicates: - X IS TRUE, - X IS NOT TRUE, - X IS FALSE, - X IS NOT FALSE were implemented by expanding the Item tree in the parser, by using a construct like: Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>) Each <value> was a constant integer, either 0 or 1. A bug in the implementation of the function IF(a, b, c), in Item_func_if::fix_length_and_dec(), would cause the following : When the arguments b and c are both unsigned, the result type of the function was signed, instead of unsigned. When the result of the if function is signed, space for the sign could be counted twice (in the max() expression for a signed argument, and in the total), causing the member max_length to be too high. An effect of this is that the final type of IF(x, int(1), int(1)) would be int(2) instead of int(1). With this fix, the problems found in Item_func_if::fix_length_and_dec() have been fixed. While it's semantically correct to represent 'X IS TRUE' with Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>), there are however more problems with this construct. a) Building the parse tree involves : - creating 5 Item instances (3 ints, 1 ifnull, 1 if), - creating each Item calls my_pthread_getspecific_ptr() once in the operator new(size), and a second time in the Item::Item() constructor, resulting in a total of 10 calls to get the current thread. Evaluating the expression involves evaluating up to 4 nodes at runtime. This representation could be greatly simplified and improved. b) Transforming the parse tree internally with if(ifnull(...)) is fine as long as this transformation is internal to the server implementation. With views however, the result of the parse tree is later exposed by the ::print() functions, and stored as part of the view definition. Doing this has long term consequences: 1) The original semantic 'X IS TRUE' is lost, and replaced by the if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore the original code. 2) Should a future version of MySQL implement the SQL BOOLEAN data type for example, views created today using 'X IS NULL' can be exported using mysqldump, and imported again. Such views would be converted correctly and automatically to use a BOOLEAN column in the future version. With 'X IS TRUE' and the current implementations, views using these "boolean" predicates would not be converted during the export/import, and would use integer columns instead. The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but does not preserve the 'X IS TRUE' semantic. With this fix, internal representation of 'X IS TRUE' booleans predicates has changed, so that: - dedicated Item classes are created for each predicate, - only 1 Item is created to represent 1 predicate - my_pthread_getspecific_ptr() is invoked 1 time instead of 10 - SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'. Note that, because of the fix in Item_func_if, views created before this fix will: - correctly use a int(1) type instead of int(2) for boolean predicates, - incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW, since the original semantic (X IS TRUE) has been lost. - except for the syntax used in SHOW CREATE VIEW, these views will operate properly, no action is needed. Views created after this fix will operate correctly, and will preserve the original code semantic in SHOW CREATE VIEW.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
-
gkodinov/kgeorge@macbook.gmz authored
Common symbols with and without initialization cause the apple linker to exclude then from the list of global symbols.
-
tnurnberg@mysql.com/sin.azundris.com authored
into mysql.com:/home/tnurnberg/24660/50-24660
-
tnurnberg@mysql.com/sin.azundris.com authored
into mysql.com:/home/tnurnberg/24660/41-24660
-
tnurnberg@mysql.com/sin.azundris.com authored
into mysql.com:/home/tnurnberg/24660/50-24660
-
tnurnberg@mysql.com/sin.azundris.com authored
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.
-
gluh@mysql.com/eagle.(none) authored
The crash happens because second filling of the same I_S table happens in case of subselect with order by. table->sort.io_cache previously allocated in create_sort_index() is deleted during second filling (function get_schema_tables_result). There are two places where I_S table can be filled: JOIN::exec and create_sort_index(). To fix the bug we should check if the table was already filled in one of these places and skip processing of the table in second.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
Some fields (GEOMETRY first of all) can't be handled properly in this case at all. So we return an error in this case
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26159
-
igor@olga.mysql.com authored
The function make_unireg_sortorder ignored the fact that any view field is represented by a 'ref' object. This could lead to wrong results for the queries containing both GROUP BY and ORDER BY clauses.
-
- 11 Feb, 2007 3 commits
-
-
evgen@moonbone.local authored
Post fix for bug#12122. information_schema.result: Corrected test case after fixing bug#12122.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/12122-bug-5.0-opt-mysql
-
igor@olga.mysql.com authored
A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset caused a crash when a query with DISTINCT was executed by a loose scan for an InnoDB table that had been emptied.
-
- 09 Feb, 2007 1 commit
-
-
evgen@moonbone.local authored
present. A view created with CREATE VIEW ... ORDER BY ... cannot be resolved with the MERGE algorithm, even when no other part of the CREATE VIEW statement would require the view to be resolved using the TEMPTABLE algorithm. The check for presence of the ORDER BY clause in the underlying select is removed from the st_lex::can_be_merged() function. The ORDER BY list of the underlying select is appended to the ORDER BY list
-