{"push_id":937841491,"size":351,"distinct_size":1,"ref":"refs/heads/5.6","head":"9dba27386d59892dd400767f09a39d0e3e3179a8","before":"961958f355d93f9d015de818e9ea1a6eeb1029d2","commits":[{"sha":"60d2c2b477187a70c5e26ae4f05210f42152b5c3","author":{"email":"4025aab300f58d3c3c34aa0a55f93939eedaf2b8@oracle.com","name":"Balasubramanian Kandasamy"},"message":"Raise version number after cloning 5.6.25","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/60d2c2b477187a70c5e26ae4f05210f42152b5c3"},{"sha":"71504da0f99c90891962baa5c3067a3fb26130ad","author":{"email":"26f57213aef288c85f26f07fb1fa02595c01b862@oracle.com","name":"Marc Alff"},"message":"Bug#20963147 DECOUPLE DIGEST SIZE FROM SERVER AND PFS\n\nBefore this fix, the server variable 'max_digest_size'\nwas used in two places.\n\n1)\n\nDuring query parsing, the server collects the statement digest text,\nand store the digest in a buffer of size 'max_digest_size'.\n\nOnly 1 digest text per session is needed at the same time,\nwhich limits the memory consumption.\n\n2)\n\nIn the performance schema, the digests collected in 1) are\ncopied in various tables, and the memory allocated to\nkeep digest historical or aggregated data also depends on 'max_digest_size'.\n\nMany digests text per session are preserved at the same time,\nso that the total memory consumption is a multiple of 'max_digest_size',\nmaking this parameter sensitive.\n\nThe problem is that for some deployments,\nnamely when using either the firewall plugin or the query rewrite plugin,\nDBA typically need to have at the same time:\n- a big value for 1), to avoid truncation\n- a lower value for 2), to limit memory consumption,\n  even if truncations can occur in the recorded performance schema data.\n\nThe solution is to keep variable 'max_digest_size' for part 1),\nand create a separate variable 'performance_schema_max_digest_size' for part\n2), so that sizing for the firewall/query rewrite can be independent of the\nperformance schema.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/71504da0f99c90891962baa5c3067a3fb26130ad"},{"sha":"438e8031936d95f4b16b594f13421e3b241e5aa6","author":{"email":"da39a3ee5e6b4b0d3255bfef95601890afd80709","name":"mysql-builder@oracle.com"},"message":"","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/438e8031936d95f4b16b594f13421e3b241e5aa6"},{"sha":"e7706808691d291a5b0528e05965964089178c39","author":{"email":"da39a3ee5e6b4b0d3255bfef95601890afd80709","name":"mysql-builder@oracle.com"},"message":"","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/e7706808691d291a5b0528e05965964089178c39"},{"sha":"d3cfb44af1e364ed3e601a4e094155b4ee412f11","author":{"email":"26f57213aef288c85f26f07fb1fa02595c01b862@oracle.com","name":"Marc Alff"},"message":"Test cleanup","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/d3cfb44af1e364ed3e601a4e094155b4ee412f11"},{"sha":"db23392bac27ad3e84319229ee3db9921b734abd","author":{"email":"0af627adff678070af2a3615242f9b46327ff8e8@oracle.com","name":"Debarun Banerjee"},"message":"BUG#20977779 CANNOT IMPORT TABLES CONTAINING PREFIX INDEXES\n\nProblem :\n---------\nWhile importing table, we are getting the index columns\nfrom cfg by name and hence if a column is repeated we get\nthe first reference always. If the first and second reference\nhas different prefix length, the validation fails.\n\nSolution :\n----------\nCheck all index column in dictionary and cfg one to one. The\nfix expects cfg and dictionary to match exactly.\n\nReviewed-by: Kevin Lewis <kevin.lewis@oracle.com>\nReviewed-by: Marko Makela <marko.makela@oracle.com>\n\nRB: 8774","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/db23392bac27ad3e84319229ee3db9921b734abd"},{"sha":"70fd349d1289d0d28cc3eb30f822687a618fd89b","author":{"email":"0af627adff678070af2a3615242f9b46327ff8e8@oracle.com","name":"Debarun Banerjee"},"message":"BUG#20768847 ASSERTION 0 IN HA_INNOBASE::COMMIT_INPLACE_ALTER_TABLE\n\nProblem :\n---------\nWe are incorrectly dropping an index in parent table with foreign key\ndependency. While checking whether it is ok to drop an index, we check\nonly the first FK reference to and from other tables. For multiple\nforeign key references the check is insufficient.\n\nSolution :\n----------\nLoop and check for all foreign key references to and from the table to\ncheck if it is safe to drop an index.\n\nReviewed-by: Marko Makela <Marko.Makela@oracle.com>\n\nRB: 8734","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/70fd349d1289d0d28cc3eb30f822687a618fd89b"},{"sha":"751a3da76dfd66b92395f90f11fce6bd890c9db5","author":{"email":"f6508a68e6ec0878dd05667c724300c4722b3bed@oracle.com","name":"Joao Gramacho"},"message":"BUG#18731252 SLAVES WITH SAME SERVER_ID / SERVER_UUID COMPETE FOR\n             MASTER CONNECTION\n\nWhen two slaves with same UUID are configured to replicate from a\nsingle master, the I/O thread of the slaves keep reconnecting and\ngenerating a new relay log files almost without new content.\n\nAnalysis:\n\nThe master server do not allow two slave connections with same UUID.\n\nOnce a new connection is made from a slave with a given UUID, the\nmaster disconnects the older connection, keeping only one slave\nconnection per slave UUID.\n\nOn the other side, as the master doesn't report any errors to\nthe slave, the I/O thread of the disconnected slave will try to\nreconnect, generating a new relay log file.\n\nFix:\n\nThe master now throws an error to the slave once detecting a\nduplicate UUID. By receiving an error from the master, the I/O\nthread will not try to reconnect anymore.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/751a3da76dfd66b92395f90f11fce6bd890c9db5"},{"sha":"44f5c2e7118e74aeb6e9136a206e4dc6eb769f54","author":{"email":"f6508a68e6ec0878dd05667c724300c4722b3bed@oracle.com","name":"Joao Gramacho"},"message":"Post push fix for BUG#18731252\n\nFixed some issues with rpl_server_uuid test case.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/44f5c2e7118e74aeb6e9136a206e4dc6eb769f54"},{"sha":"d402696855d902ddad4455bfaed79bbab871880d","author":{"email":"00d60cc77e35578fec83c0a705084084dd26aeb1@oracle.com","name":"Christopher Powers"},"message":"Bug#20738072 CRASH ON STARTUP WITH MAX-DIGEST-LENGTH OF >=420K\n\nCheck for multiplication overflow before allocating Performance Schema arrays during server initialization.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/d402696855d902ddad4455bfaed79bbab871880d"},{"sha":"e7b6e814bea7a9e21ef864016bde39fd65a7f655","author":{"email":"3dd7fa59519d1d3dbf7043cc4f1397eca520ea4c@oracle.com","name":"Annamalai Gurusami"},"message":"Bug #19138298 RECORD IN INDEX WAS NOT FOUND ON ROLLBACK, TRYING TO INSERT\n\nScenario:\n\n1. The purge thread takes an undo log record and parses it and forms\n   the record to be purged. We have the primary and secondary keys\n   to locate the actual records.\n2. Using the secondary index key, we search in the secondary index.\n   One record is found.\n3. Then it is checked if this record can be purged.  The answer is we\n   can purge this record.  To determine this we look up the clustered\n   index record.  Either there is no corresponding clustered index\n   record, or the matching clustered index record is delete marked.\n4. Then we check whether the secondary index record is delete marked.\n   We find that it is not delete marked.  We report warning in optimized\n   build and assert in debug build.\n\nProblem:\n\nIn step 3, we report that the record is purgeable even though it is\nnot delete marked.  This is because of inconsistency between the\nfollowing members of purge_node_t structure - found_clust, ref and pcur.\n\nSolution:\n\nIn the row_purge_reposition_pcur(), if the persistent cursor restore\nfails, then reset the purge_node_t->found_clust member.  This will\nkeep the members of purge_node_t structure in a consistent state.\n\nrb#8813 approved by Marko.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/e7b6e814bea7a9e21ef864016bde39fd65a7f655"},{"sha":"b984d61dffc804366bff811f67d5308c0df17dec","author":{"email":"3dd7fa59519d1d3dbf7043cc4f1397eca520ea4c@oracle.com","name":"Annamalai Gurusami"},"message":"Bug #19138298 RECORD IN INDEX WAS NOT FOUND ON ROLLBACK, TRYING TO INSERT\n\nNull merge from mysql-5.5 to mysql-5.6","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/b984d61dffc804366bff811f67d5308c0df17dec"},{"sha":"982a157c71667040838def7a00d951ffc55eccbc","author":{"email":"3dd7fa59519d1d3dbf7043cc4f1397eca520ea4c@oracle.com","name":"Annamalai Gurusami"},"message":"Bug #19138298 RECORD IN INDEX WAS NOT FOUND ON ROLLBACK, TRYING TO INSERT\n\nScenario:\n\n1. The purge thread takes an undo log record and parses it and forms\n   the record to be purged. We have the primary and secondary keys\n   to locate the actual records.\n2. Using the secondary index key, we search in the secondary index.\n   One record is found.\n3. Then it is checked if this record can be purged.  The answer is we\n   can purge this record.  To determine this we look up the clustered\n   index record.  Either there is no corresponding clustered index\n   record, or the matching clustered index record is delete marked.\n4. Then we check whether the secondary index record is delete marked.\n   We find that it is not delete marked.  We report warning in optimized\n   build and assert in debug build.\n\nProblem:\n\nIn step 3, we report that the record is purgeable even though it is\nnot delete marked.  This is because of inconsistency between the\nfollowing members of purge_node_t structure - found_clust, ref and pcur.\n\nSolution:\n\nIn the row_purge_reposition_pcur(), if the persistent cursor restore\nfails, then reset the purge_node_t->found_clust member.  This will\nkeep the members of purge_node_t structure in a consistent state.\n\nrb#8813 approved by Marko.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/982a157c71667040838def7a00d951ffc55eccbc"},{"sha":"515b2203c5913679757fa2cf39f017001f7e29ee","author":{"email":"cf76068089fe2168a7cd73d620466fc868c313f4@oracle.com","name":"Ajo Robert"},"message":"Bug #18075170 SQL NODE RESTART REQUIRED TO\nAVOID DEADLOCK AFTER RESTORE\n\nAnalysis\n--------\nAccessing the restored NDB table in an active multi-statement\ntransaction was resulting in deadlock found error.\n\nMySQL Server needs to discover metadata of NDB table from\ndata nodes after table is restored from backup. Metadata\ndiscovery happens on the first access to restored table.\nCurrent code mandates this statement to be the first one\nin the transaction. This is because discover needs exclusive\nmetadata lock on the table. Lock upgrade at this point can\nlead to MDL deadlock and the code was written at the time\nwhen MDL deadlock detector was not present. In case when\ndiscovery attempted in the statement other than the first\none in transaction ER_LOCK_DEADLOCK error is reported\npessimistically.\n\nFix:\n---\nRemoved the constraint as any potential deadlock will be\nhandled by deadlock detector. Also changed code in discover\nto keep metadata locks of active transaction.\n\nSame issue was present in table auto repair scenario. Same\nfix is added in repair path also.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/515b2203c5913679757fa2cf39f017001f7e29ee"},{"sha":"28ef4ac3db9f6be71ccbea1ac2d7dd7ba5af5fb6","author":{"email":"00d60cc77e35578fec83c0a705084084dd26aeb1@oracle.com","name":"Christopher Powers"},"message":"Bug#20738072 CRASH ON STARTUP WITH MAX-DIGEST-LENGTH OF >=420K\n\nFix unit test.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/28ef4ac3db9f6be71ccbea1ac2d7dd7ba5af5fb6"},{"sha":"bdacb31360d83185cc0bbe23daeb0d26e7e7327d","author":{"email":"00d60cc77e35578fec83c0a705084084dd26aeb1@oracle.com","name":"Christopher Powers"},"message":"Bug#20738072 CRASH ON STARTUP WITH MAX-DIGEST-LENGTH OF >=420K\n\nFix unit test count, pfs_misc-t.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/bdacb31360d83185cc0bbe23daeb0d26e7e7327d"},{"sha":"fce558959bd0e5af1ae6aac3d8573db00c271dfd","author":{"email":"1e8e3bac36d85782b34408b94459da13dba11a6a@oracle.com","name":"Sujatha Sivakumar"},"message":"Bug#19316063: MAKE MTS WORK WITH RELAY_LOG_RECOVERY=1 WHEN\nGTID IS ENABLED\n\nAnalysis:\n========\nWhen GTID is enabled, MTS don't need to care about gaps.\n\nIf the auto position replication protocol is enabled, it\nwill make dump thread handle all of the gaps on master side.\n\nIf the auto position replication protocol is not enabled,\nthe dump thread will start replicating from the first gap\nand the GTID auto skip feature will make sure that the\nalready applied transactions will not be applied twice.\n\nFix:\n===\nDuring relay log recovery process check if GTID mode is\nenabled or not. If enabled reset the MTS recovery process\nso that GTID protocol can fill the MTS gaps.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/fce558959bd0e5af1ae6aac3d8573db00c271dfd"},{"sha":"820bf7b1f17fbaedb1061c7c845e755e6ebc1572","author":{"email":"cf76068089fe2168a7cd73d620466fc868c313f4@oracle.com","name":"Ajo Robert"},"message":"Bug #18075170 SQL NODE RESTART REQUIRED TO\nAVOID DEADLOCK AFTER RESTORE\n\nTest Failure Fix.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/820bf7b1f17fbaedb1061c7c845e755e6ebc1572"},{"sha":"ca07f13f185473664255d94eb6aa83e78aeac0f5","author":{"email":"cf76068089fe2168a7cd73d620466fc868c313f4@oracle.com","name":"Ajo Robert"},"message":"Merge branch 'mysql-5.5' into mysql-5.6","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/ca07f13f185473664255d94eb6aa83e78aeac0f5"},{"sha":"5dd0bc2ff6adb2874b6e8cb83409b8e83a9eb296","author":{"email":"00d60cc77e35578fec83c0a705084084dd26aeb1@oracle.com","name":"Christopher Powers"},"message":"Bug#20738072 CRASH ON STARTUP WITH MAX-DIGEST-LENGTH OF >=420K\n\nFix skip test count, pfs_misc-t.","distinct":false,"url":"https://api.github.com/repos/prohaska7/mysql-server/commits/5dd0bc2ff6adb2874b6e8cb83409b8e83a9eb296"}]}