{"push_id":645156741,"size":22,"distinct_size":21,"ref":"refs/heads/5.5","head":"76fb695c0f57b66709f2fdc3d4254ba0b1c80d12","before":"c6661f0ffad71bde26acb28e11836b3ff198f3fc","commits":[{"sha":"d009d48d8cae272d1675b88a8eebae4b6090e454","author":{"email":"4025aab300f58d3c3c34aa0a55f93939eedaf2b8@oracle.com","name":"Bala"},"message":"Raise version number after cloning 5.5.42","distinct":false,"url":"https://api.github.com/repos/percona/percona-server/commits/d009d48d8cae272d1675b88a8eebae4b6090e454"},{"sha":"23321f629b465f17fd0d91d442aa736183b355b2","author":{"email":"7e921a6e2914d9065bd30bb68c8e7f7d08e791c7@oracle.com","name":"Praveenkumar.Hulakund"},"message":"Bug#19786309 -  CRASH IN UNLOCK TABLES AFTER LOCKING AND TRUNCATING TEMPORARY TABLE.\n\nAttempt to truncate temporary table using Blackhole storage and\nlocked by LOCK TABLES caused assertion failure and crashes.\n\nBlackhole is a transaction-aware engine. While creating the temporary\ntable in transaction-aware engine, temporary table of type\n\"TRANSACTIONAL_TMP_TABLE\" is created. For such temporary tables\na THR_LOCK lock is acquired by the LOCK TABLE operation. References\nto them are also added into MYSQL_LOCK::table[] array. Also for\nBlackhole engine, flag HTON_CAN_RECREATE is set.\n\nWhile truncating temporary tables, no locks are taken and\nrecreate_temporary_table() is called for engines having\n\"HTON_CAN_RECREATE\" in flag.\n\nFunction closefrm() is called from the recreate_temporary_table(),\nto close the current temporary table. In closefrm(), the lock on\ntable expected is \"F_UNLCK\". In debug builds, assert condition on\nthis fails when lock of type \"F_WRLCK\" is acquired by LOCK TABLE\noperation on temporary tables using Blackhole engine.\n\nIn non-debug builds closefrm() simply freed TABLE object leaving\ndangling pointer to this object in MYSQL_LOCK::table[] array which\nmight lead to crashes later.\n\nFix:\n---------\nTo fix this issue, we now unlock and remove table from MYSQL_LOCK::table[]\narray before calling close_temporary_table() in recreate_temporary_table().\nThis is achieved by calling mysql_lock_remove() function for this table.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/23321f629b465f17fd0d91d442aa736183b355b2"},{"sha":"ebb2a3f5e17c5698bd7f78ab80938708c897d407","author":{"email":"b5d5cefbbc0522dcc0095c82aaa117bff2696d84@oracle.com","name":"Venkatesh Duggirala"},"message":"Problem: IO thread fails to connect to master if servers are configured with\nspecial character sets like utf16, utf32, ucs2.\n\nAnalysis: MySQL server does not support few special character sets like\n  utf16,utf32 and ucs2 as \"client's character set\"(eg: utf16,utf32, ucs2).\n  It is known limitation listed in the documentation\n  http://dev.mysql.com/doc/refman/5.5/en/charset-connection.html.\n\n  The default value for default-character-set parameter is 'auto'\n  which means that if the server's character set is not supported,\n  then server automatically changes client's character set to\n  predefined character-set which is 'latin1' in the current code.\n\n  Eg:\n  $ ./mysql -uroot -S$SOCKET_FILE --default-character-set=utf16\n  ERROR 1231 (42000): Variable 'character_set_client' can't be set to the value of 'utf16'\n\n  $ ./mysql -uroot -S$SOCKET_FILE will be successfully connected to\n  server with 'latin1' as default client side character set.\n\n  When IO thread is trying to connect to Master, it sets server's character\n  set as client's character set. When Slave server is started with these\n  special character sets, IO thread (which is like a connection to Master)\n  fails because of the above said limitation.\n\n Fix: Now even IO thread also behaves the same as a regular client behaves.\n  i.e., If server's character set is not supported as client's character set,\n  then set default's client character set(latin1) as client's character set.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/ebb2a3f5e17c5698bd7f78ab80938708c897d407"},{"sha":"e84b3fd4ff5053d7335ad4296188fa8149939296","author":{"email":"4025aab300f58d3c3c34aa0a55f93939eedaf2b8@oracle.com","name":"Bala"},"message":"Updated file_contents test for sles packages","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/e84b3fd4ff5053d7335ad4296188fa8149939296"},{"sha":"2750b4b7386741945ae47bf22bba78d0b7792764","author":{"email":"8be6d7d3bb110b36aa260939fff4edff05761a5b@oracle.com","name":"Jon Olav Hauglid"},"message":"Bug#20344207: Add support for CMake 3.1\n\nRename a CMake variable in compile_flags.cmake to avoid triggering\nCMake 3.1 warning about CMP0054 about interpreting if() arguments\nas keywords or variables.\n\nNo changes in behavior.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/2750b4b7386741945ae47bf22bba78d0b7792764"},{"sha":"a3e9500823d40d3959353b08577a1e98c2426bf2","author":{"email":"4025aab300f58d3c3c34aa0a55f93939eedaf2b8@oracle.com","name":"Bala"},"message":"Bug#17619241 SERVICE OR MYSQLD_SAFE STARTS PICKING WRONG PLUGIN DIRECTORY","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/a3e9500823d40d3959353b08577a1e98c2426bf2"},{"sha":"c9f307c456c546c76074dceea2e2464507cf2a2f","author":{"email":"a1f315458d71b04281ff9260b9bc0741bb1ce421@oracle.com","name":"Thayumanavar"},"message":"BUG#19875331 - HANDLE_FATAL_SIGNAL 11 IN STRMAKE\n\nProblem Description And Fix:\nInserting a fudged record in mysql.proc with the dbname\ncolumn value as test and the name column as empty, will\ncause a crash in mysqld when we run the command DROP\nDATABASE test.\n During DROP DATABASE test, mysql_rm_db subsequently\ncalls lock_db_routines. In the routine we fetch the\nfield 'name' from mysql.proc by calling the underlying\nstorage engine API in lock_db_routines. This cause NULL\nvalue as the field column of mysql.proc and subsequent\ndereference MDL_request::init leads to crash.\nModifying mysql.proc using SQL command by user is not\nsupported, but in principle, there is a possibility\nof mysql.proc getting corrupted which can also lead\nto empty fields and arbitary values. The patch fixes\nthe crash by checking NULL and propagating the appopriate\nerror code to the user.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/c9f307c456c546c76074dceea2e2464507cf2a2f"},{"sha":"70f5d81a96ba38d690e907f5fd56760b9ee87803","author":{"email":"1e8e3bac36d85782b34408b94459da13dba11a6a@oracle.com","name":"s.sujatha"},"message":"Bug#20041860: SLAVE ERROR WHEN DROP DATABASE\n\nFixing a post push test issue.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/70f5d81a96ba38d690e907f5fd56760b9ee87803"},{"sha":"7a408dbdf40930144c1bad654cb1e31e5ce5fc7a","author":{"email":"8be6d7d3bb110b36aa260939fff4edff05761a5b@oracle.com","name":"Jon Olav Hauglid"},"message":"Bug#19770858: MYSQLD CAN BE DRIVEN TO OOM WITH TWO SIMPLE SESSION VARS\n\nThe problem was that the maximum value of the transaction_prealloc_size\nsession system variable was ULONG_MAX which meant that it was possible\nto cause the server to allocate excessive amounts of memory.\n\nThis patch fixes the problem by reducing the maxmimum value of\ntransaction_prealloc_size and transaction_alloc_block_size down\nto 128K.\n\nNote that transactions will still be able to allocate more than\n128K if needed, this patch just reduces the amount that can be\npreallocated - as well as the maximum size of the incremental\nallocation blocks.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/7a408dbdf40930144c1bad654cb1e31e5ce5fc7a"},{"sha":"aa1de7372846e3a37c87b7488d34426264d7da44","author":{"email":"9ffc149b0501269f20f01eb531ae5c68d28d83ac@oracle.com","name":"Nisha Gopalakrishnan"},"message":"Bug#20094067: BACKPORT BUG#19683834 TO 5.5 AND 5.6\n\nBackporting the patch and the test case fixed as part\nof BUG#16041903 and BUG#19683834 respectively.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/aa1de7372846e3a37c87b7488d34426264d7da44"},{"sha":"08526dfb0109a5809101ec7818a9514b2f5ea606","author":{"email":"57a9461ad3972b3802cf500c927040dc082abf56@oracle.com","name":"Arun Kuruvila"},"message":"Bug #12671631 CREATE TABLE .. LIKE .. FEDERATED TABLE\n              CRASHES WITH AUTO_INCREMENT COLUMN\n\nDescription:- Creating a federated table with AUTO_INCREMENT\ncolumn using LIKE clause results in a server crash.\n\nAnalysis:- Creating a federated table with AUTO_INCREMENT\ncolumn using LIKE clause results in a federated server\ncrash due to the uninitialized connection structure(mysql).\nAlso due to unassigned connection string for the remote\nserver, at the time of preparation of \"create_info\"\nstructure, the creation of any federated table using LIKE\nclause fails with an error, \"ERROR 1 (HY000): server name:\n'' doesn't exist!\". This  bug is not only with\nAUTO_INCREMENT but in all creations of federated tables with\nLIKE clause.\n\nFix :- In ha_federated::info(), \"mysql->insert_id\" assigned\nto \"stats.auto_increment_value\" only when there is an\nactive connection. This fixes the crash issue. For creating\nthe federated table with LIKE clause, connection string is\nassigned at the time of preparation of \"create_info\"\nstructure.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/08526dfb0109a5809101ec7818a9514b2f5ea606"},{"sha":"c9f7948bc47edc7ddc3b3693b9a3e4b623a97ca6","author":{"email":"57687871af7f47895a7e21d9802a5e3cfba15870@oracle.com","name":"Mithun C Y"},"message":"Bug #19892803: ASSERTION FAILED: N < M_SIZE WITH DISTINCT TIME\n\nISSUE:\n------\nWe pre-allocate the ref_pointer_array before we resolve outer\nreferences. This means that in some cases the\nref_pointer_array may not be large enough to hold all\nreferences created. One such case is aggregate functions in\nhaving clause of a subquery which may add items to select list\nof outer query. So it is necessary to consider\nselect_n_having_items for subqueries while allocating\nref_pointer_array else we will get buffer overflow.\n\nSOLUTION:\n---------\nAllocate a larger ref_pointer_array by aggregating\nselect_n_having_items for subqueries.\nThe fix in sql_yacc.yy is a backport from bug fix 18782905.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/c9f7948bc47edc7ddc3b3693b9a3e4b623a97ca6"},{"sha":"3c4a659958a1e3afe65e76e5b7e385949f542586","author":{"email":"4025aab300f58d3c3c34aa0a55f93939eedaf2b8@oracle.com","name":"Bala"},"message":"Merge branch 'mysql-5.5.42-release' into mysql-5.5","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/3c4a659958a1e3afe65e76e5b7e385949f542586"},{"sha":"17c97553056edc86317f543c495b5374603709fb","author":{"email":"675b1c4b9de061e0ce011ae43a19257c7860586d@oracle.com","name":"sreeharsha"},"message":"Bug # 19699237: UNINITIALIZED VARIABLE IN ITEM_FIELD::STR_RESULT\nLEADS TO INCORRECT BEHAVIOR\n\nISSUE:\n------\nWhen the following conditions are satisfied in a query, a\nserver crash occurs:\na) Two rows are compared using a NULL-safe equal-to operator.\nb) Each of these rows belong to different charsets.\n\nSOLUTION:\n---------\nWhen one charset is converted to another for comparision,\nthe constructor of \"Item_func_conv_charset\" is called.\nThis will attempt to use the Item_cache if the string is a\nconstant. This check succeeds because the \"used_table_map\"\nof the Item_cache class is never set to the correct value.\nSince it is mistakenly assumed to be a constant, it tries\nto fetch the relevant null value related fields which are\nyet to be initialized. This results in valgrind issues\nand wrong results.\n\nThe fix is to update the \"used_table_map\" of \"Item_cache\".\nThis will allow \"Item_func_conv_charset\" to realise that\nthis is not a constant.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/17c97553056edc86317f543c495b5374603709fb"},{"sha":"ddd275bde7a8edb64449761989d4d472739b3d2a","author":{"email":"7e921a6e2914d9065bd30bb68c8e7f7d08e791c7@oracle.com","name":"Praveenkumar.Hulakund"},"message":"Bug#20052694 - FAILED RESTARTS CONTAIN NO VERSION DETAILS.\n\nIn versions 5.5 and 5.6 the MySQL version is not logged until\nserver is started and ready to accept connections. Exiting\nserver before this point will not have server version information\nin the log. But in 5.7 code, we log a server version information\njust after we prepare server_version string and logging is initialized.\n\nFor 5.5 and 5.6 code also adding this code to print server version\ninformation.\n\nTest results:\n================\n\n5.5\n-----\nServer version will be logged as below on server startup:\n141218  8:45:48 [Note] /home/praveen/WorkDir/mysql_local/bug20052694/mysql/sql/mysqld (mysqld 5.5.42-debug-log) starting as process 19697 ...\n\n5.6\n----\nServer version will be logged as below on server startup:\n2014-12-18 09:08:43 0 [Note] /home/praveen/WorkDir/mysql_local/bug20052694/mysql-5.6/sql/mysqld (mysqld 5.6.23-debug-log) starting as process 18474 ...","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/ddd275bde7a8edb64449761989d4d472739b3d2a"},{"sha":"1a5b8122b615d07223ed4855ae35c511bcedd5fc","author":{"email":"1b24d5894a25cc02f54ec1fc676a1dfb6a6cbced@oracle.com","name":"Chaithra Gopalareddy"},"message":"Bug #19612819 :  FILESORT: ASSERTION FAILED: POS->FIELD != 0 || POS->ITEM != 0\n\nProblem:\nWhile getting the temp table field for a REF_ITEM\nmake_sortorder is using the real_item. As a result\nserver fails later with an assert.\n\nSolution:\nDo not use real_item to get the temp table field.\nInstead use the REF_ITEM itself as temp table fields\nare created for REF_ITEM not the real_item.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/1a5b8122b615d07223ed4855ae35c511bcedd5fc"},{"sha":"674367afd56f93bac4fddde6c6e422c17591d0d2","author":{"email":"1b24d5894a25cc02f54ec1fc676a1dfb6a6cbced@oracle.com","name":"Chaithra Gopalareddy"},"message":"Bug#19880368 : GROUP_CONCAT CRASHES AFTER DUMP_LEAF_KEY\n\nProblem:\nfind_order_by_list does not update the address of order_item\ncorrectly after resolving.\n\nSolution:\nChange the ref_by address for a order_by field if its\nSUM_FUNC_ITEM to the address of the field present in\nall_fields.","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/674367afd56f93bac4fddde6c6e422c17591d0d2"},{"sha":"f922bb745ae2ed0638d92b7657fd0b635ce9fb5f","author":{"email":"4025aab300f58d3c3c34aa0a55f93939eedaf2b8@oracle.com","name":"Balasubramanian Kandasamy"},"message":"Updated copyright information","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/f922bb745ae2ed0638d92b7657fd0b635ce9fb5f"},{"sha":"1e1630337505593fa2c414c55e3f410e979740dc","author":{"email":"3df4c7816af7135b33362e629829688144c1edd9@oracle.com","name":"Terje Røsten"},"message":"BUG#20477758 CONFLICTS WHILE INSTALLING COMMUNITY PACKAGES WHEN MARIADB, LIB FILES INSTALLED\n\nDue to large version numbers used libmysqlclient-devel packages was\nnot considered for install. Fixed by removing version check.\n\nSigned-off-by: Terje Røsten <terje.rosten@oracle.com>","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/1e1630337505593fa2c414c55e3f410e979740dc"},{"sha":"e02fe87f00dc9fdb0fb6ab13f2e87485f79f3341","author":{"email":"3df4c7816af7135b33362e629829688144c1edd9@oracle.com","name":"Terje Røsten"},"message":"BUG#19811871 VERSION NUMBR NOT SHOWN IN LOG WHEN [RE]STARTING 5.6.21 SERVICE WITH SLES11 REPO\n\nLog file directory had too strict access rights, server not able\nto write to log file.\n\nSigned-off-by: Terje Røsten <terje.rosten@oracle.com>","distinct":true,"url":"https://api.github.com/repos/percona/percona-server/commits/e02fe87f00dc9fdb0fb6ab13f2e87485f79f3341"}]}