Skip to content

M
MariaDB
Switch branch/tag
  1. 25 May, 2007 1 commit
    • unknown's avatar
      Bug#27876 (SF with cyrillic variable name fails during execution (regression)) · 1e33b063
      unknown authored 
      The root cause of this bug is related to the function skip_rear_comments,
in sql_lex.cc

Recent code changes in skip_rear_comments changed the prototype from
"const uchar*" to "const char*", which had an unforseen impact on this test:
  (endp[-1] < ' ')
With unsigned characters, this code filters bytes of value [0x00 - 0x20]
With *signed* characters, this also filters bytes of value [0x80 - 0xFF].

This caused the regression reported, considering cyrillic characters in the
parameter name to be whitespace, and truncated.
Note that the regression is present both in 5.0 and 5.1.

With this fix:
- [0x80 - 0xFF] bytes are no longer considered whitespace.
This alone fixes the regression.

In addition, filtering [0x00 - 0x20] was found bogus and abusive,
so that the code now filters uses my_isspace when looking for whitespace.

Note that this fix is only addressing the regression affecting UTF-8
in general, but does not address a more fundamental problem with
skip_rear_comments: parsing a string *backwards*, starting at end[-1],
is not safe with multi-bytes characters, so that end[-1] can confuse the
last byte of a multi-byte characters with a characters to filter out.

The only known impact of this remaining issue affects objects that have to
meet all the conditions below:

- the object is a FUNCTION / PROCEDURE / TRIGGER / EVENT / VIEW
- the body consist of only *1* instruction, and does *not* contain a
  BEGIN-END block
- the instruction ends, lexically, with <ident> <whitespace>* ';'?
  For example, "select <ident>;" or "return <ident>;"
- The last character of <ident> is a multi-byte character
- the last byte of this character is ';' '*', '/' or whitespace

In this case, the body of the object will be truncated after parsing,
and stored in an invalid format.

This last issue has not been fixed in this patch, since the real fix
will be implemented by Bug 25411 (trigger code truncated), which is caused
by the very same code.
The real problem is that the function skip_rear_comments is only a
work-around, and should be removed entirely: see the proposed patch for
bug 25411 for details.


sql/sp_head.cc:
  In skip_rear_comments,
  Filter out only whitespace, not other (non ascii or control) valid characters
sql/sql_lex.cc:
  In skip_rear_comments,
  Filter out only whitespace, not other (non ascii or control) valid characters
sql/sql_lex.h:
  In skip_rear_comments,
  Filter out only whitespace, not other (non ascii or control) valid characters
sql/sql_view.cc:
  In skip_rear_comments,
  Filter out only whitespace, not other (non ascii or control) valid characters
tests/mysql_client_test.c:
  Bug#27876 (SF with cyrillic variable name fails during execution (regression))
      1e33b063
  3. 24 May, 2007 1 commit
  5. 23 May, 2007 4 commits
    • unknown's avatar
      5.0 version of fix for: · f9d7642e
      unknown authored 
       Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
             by other connections"
 Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
As well as:
 Bug #25578 "CREATE TABLE LIKE does not require any privileges
             on source table".

The first and the second bugs resulted in various errors and wrong
binary log order when one tried to execute concurrently CREATE TABLE LIKE
statement and DDL statements on source table or DML/DDL statements on its
target table.

The problem was caused by incomplete protection/table-locking against
concurrent statements implemented in mysql_create_like_table() routine.
We solve it by simply implementing such protection in proper way (see
comment for sql_table.cc for details).

The third bug allowed user who didn't have any privileges on table create
its copy and therefore circumvent privilege check for SHOW CREATE TABLE.

This patch solves this problem by adding privilege check, which was missing.

Finally it also removes some duplicated code from mysql_create_like_table().

Note that, altough tests covering concurrency-related aspects of CREATE TABLE
LIKE behaviour will only be introduced in 5.1, they were run manually for
this patch as well.


mysql-test/r/grant2.result:
  Added test for bug#25578 "CREATE TABLE LIKE does not require any privileges
  on source table".
mysql-test/t/grant2.test:
  Added test for bug#25578 "CREATE TABLE LIKE does not require any privileges
  on source table".
sql/handler.h:
  Introduced new flag for HA_CREATE_INFO::options in order to be able to
  distinguish CREATE TABLE ... LIKE from other types of CREATE TABLE.
sql/mysql_priv.h:
  mysql_create_like_table() now takes source table name not as a
  Table_ident object but as regular table list element.
sql/sql_parse.cc:
  CREATE TABLE ... LIKE implementation now uses statement's table list
  for storing information about the source table. We also use flag
  in LEX::create_info.options for distinguishing it from other types
  of CREATE TABLE.
  Finally CREATE TABLE ... LIKE now requires the same privileges on
  the source tables as SHOW CREATE TABLE. Moved this privilege check
  to check_show_create_table_access() function.
sql/sql_table.cc:
  mysql_create_like_table():
   - Provided proper protection from concurrent statements.
     This is achieved by keeping name-lock on the source table and holding
     LOCK_open mutex during whole operation. This gives protection against
     concurrent DDL on source table. Also holding this mutex makes copying
     of .frm file, call to ha_create_table() and binlogging atomic against
     concurrent DML and DDL operations on target table.
   - Get rid of duplicated code related to source database/table name
     handling. All these operations are already done in
     st_select_lex::add_table_to_list(), so we achieve the same effect
     by including source table into the statement's table list.
sql/sql_yacc.yy:
  Now we use special flag in LEX::create_info::options for distinguishing
  CREATE TABLE ... LIKE from other types of CREATE TABLE and store name
  of source table as regular element in statement's table list.
      f9d7642e
    • unknown's avatar
      Merge mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines · 351abe5a
      unknown authored 
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
      351abe5a
    • unknown's avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-5.0 · adef6736
      unknown authored 
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
      adef6736
    • unknown's avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-4.1 · e5b2adea
      unknown authored 
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines
      e5b2adea
  7. 22 May, 2007 3 commits
  9. 21 May, 2007 6 commits
  11. 19 May, 2007 2 commits
    • unknown's avatar
      Merge pilot.blaudden:/home/msvensson/mysql/bug28401/my50-bug28401 · f40047df
      unknown authored 
      into  pilot.blaudden:/home/msvensson/mysql/mysql-5.0-maint
      f40047df
    • unknown's avatar
      Bug #28401 mysql_upgrade Failed with STRICT_ALL_TABLES, ANSI_QUOTES and NO_ZERO_DATE · f52f931f
      unknown authored 
       - The SQL commands used by mysql_upgrade are written to be run
    with sql_mode set to '' - thus the scripts should change sql_mode
    for the session to make sure the SQL is legal.


mysql-test/r/mysql_upgrade.result:
  Update test result
mysql-test/t/mysql_upgrade.test:
  The SQL commands used by mysql_upgrade are written to be run
  with sql_mode set to '' - thus the scripts should change sql_mode
  for the session to make sure the SQL is legal.
scripts/mysql_system_tables_fix.sql:
  Set sql_mode to '' before running the SQL commands
  to fix system tables - backport from 5.1
      f52f931f
  13. 18 May, 2007 23 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7