| blob | 530d6b0a945ed27858c4b670192ddab136550d9f |
1 ------------------------------------------------------------
2 revno: 4061
3 tags: clone-5.1.73-build
4 committer: Tor Didriksen <tor.didriksen@oracle.com>
5 branch nick: 5.1
6 timestamp: Fri 2013-11-01 16:39:19 +0100
7 message:
8 Bug#17617945 BUFFER OVERFLOW IN GET_MERGE_MANY_BUFFS_COST WITH SMALL SORT_BUFFER_SIZE
10 get_cost_calc_buff_size() could return wrong value for the size of imerge_cost_buff.
11 ------------------------------------------------------------
12 revno: 4060
13 committer: Nuno Carvalho <nuno.carvalho@oracle.com>
14 branch nick: mysql-5.1
15 timestamp: Thu 2013-10-31 22:53:56 +0000
16 message:
17 BUG#17662398: REMOVE DUPLICATE TEST CASES
19 Remove duplicate test cases.
20 ------------------------------------------------------------
21 revno: 4059
22 committer: Venkata Sidagam <venkata.sidagam@oracle.com>
23 branch nick: 5.1
24 timestamp: Thu 2013-10-31 23:02:44 +0530
25 message:
26 Bug #12917164 DROP USER CAN'T DROP USERS WITH LEGACY
27 UPPER CASE HOST NAME ANYMORE
29 Description:
30 It is not possible to drop users with host names with upper case
31 letters in them. i.e DROP USER 'root'@'Tmp_Host_Name'; is failing
32 with error.
34 Analysis: Since the fix 11748570 we came up with lower case hostnames
35 as standard. But in the current bug the hostname is created by
36 mysql_install_db script is still having upper case hostnames.
37 So, if we have the hostname with upper case letters like(Tmp_Host_Name)
38 then we will have as it is stored in the mysql.user table.
39 In this case if use "'DROP USER 'root'@'Tmp_Host_Name';" it gives
40 error because we do compare with the lower case of hostname since the
41 11748570 fix.
43 Fix: We need to convert the hostname to lower case before storing into
44 the mysql.user table when we run the mysql_install_db script.
45 ------------------------------------------------------------
46 revno: 4058
47 committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
48 branch nick: mysql-5.1
49 timestamp: Wed 2013-10-30 04:07:07 +0100
50 message:
51 Removed non gpl file docs/mysql.info from community packages
52 ------------------------------------------------------------
53 revno: 4057
54 committer: Tor Didriksen <tor.didriksen@oracle.com>
55 branch nick: 5.1
56 timestamp: Tue 2013-10-29 17:26:20 +0100
57 message:
58 Bug#17326567 MYSQL SERVER FILESORT IMPLEMENTATION HAS A VERY SERIOUS BUG
60 The filesort implementation needs space for at least 15 records
61 (plus some internal overhead) in its main sort buffer.
62 ------------------------------------------------------------
63 revno: 4056
64 committer: Aditya A <aditya.a@oracle.com>
65 branch nick: mysql-5.1
66 timestamp: Fri 2013-10-18 12:26:28 +0530
67 message:
68 Bug#17559867 AFTER REBUILDING,A MYISAM PARTITION ENDS UP
69 AS A INNODB PARTITTION.
71 PROBLEM
72 -------
73 The correct engine_type was not being set during
74 rebuild of the partition due to which the handler
75 was always created with the default engine,
76 which is innodb for 5.5+ ,therefore even if the
77 table was myisam, after rebuilding the partitions
78 ended up as innodb partitions.
80 FIX
81 ---
82 Set the correct engine type during rebuild.
84 [Approved by mattiasj #rb3599]
85 ------------------------------------------------------------
86 revno: 4055
87 committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com>
88 branch nick: mysql-5.1
89 timestamp: Wed 2013-10-16 22:12:23 +0530
90 message:
91 Bug#17234370 LAST_INSERT_ID IS REPLICATED INCORRECTLY IF
92 REPLICATION FILTERS ARE USED.
94 Problem:
95 When Filtered-slave applies Int_var_log_event and when it
96 tries to write the event to its own binlog, LAST_INSERT_ID
97 value is written wrongly.
99 Analysis:
100 THD::stmt_depends_on_first_successful_insert_id_in_prev_stmt
101 is a variable which is set when LAST_INSERT_ID() is used by
102 a statement. If it is set, first_successful_insert_id_in_
103 prev_stmt_for_binlog will be stored in the statement-based
104 binlog. This variable is CUMULATIVE along the execution of
105 a stored function or trigger: if one substatement sets it
106 to 1 it will stay 1 until the function/trigger ends,
107 thus making sure that first_successful_insert_id_in_
108 prev_stmt_for_binlog does not change anymore and is
109 propagated to the caller for binlogging. This is achieved
110 using the following code
111 if(!stmt_depends_on_first_successful_insert_id_in_prev_stmt)
112 {
113 /* It's the first time we read it */
114 first_successful_insert_id_in_prev_stmt_for_binlog=
115 first_successful_insert_id_in_prev_stmt;
116 stmt_depends_on_first_successful_insert_id_in_prev_stmt= 1;
117 }
119 Slave server, after receiving Int_var_log_event event from
120 master, it is setting
121 stmt_depends_on_first_successful_insert_id_in_prev_stmt
122 to true(*which is wrong*) and not setting
123 first_successful_insert_id_in_prev_stmt_for_binlog. Because
124 of this problem, when the actual DML statement with
125 LAST_INSERT_ID() is parsed by slave SQL thread,
126 first_successful_insert_id_in_prev_stmt_for_binlog is not
127 set. Hence the value zero (default value) is written to
128 slave's binlog.
130 Why only *Filtered slave* is effected when the code is
131 in common place:
132 -------------------------------------------------------
133 In Query_log_event::do_apply_event,
134 THD::stmt_depends_on_first_successful_insert_id_in_prev_stmt
135 is reset to zero at the end of the function. In case of
136 normal slave (No Filters), this variable will be reset.
137 In Filtered slave, Slave SQL thread defers all IRU events's
138 execution until IRU's Query_log event is received. Once it
139 receives Query_log_event it executes all pending IRU events
140 and then it executes Query_log_event. Hence the variable is
141 not getting reset to 0, causing this bug.
143 Fix: As described above, the root cause was setting
144 THD::stmt_depends_on_first_successful_insert_id_in_prev_stmt
145 when Int_var_log_event was executed by a SQL thread. Hence
146 removing the problematic line from the code.
147 ------------------------------------------------------------
148 revno: 4054
149 committer: Venkata Sidagam <venkata.sidagam@oracle.com>
150 branch nick: 5.1
151 timestamp: Wed 2013-10-16 14:14:44 +0530
152 message:
153 Bug#16900358 FIX FOR CVE-2012-5611 IS INCOMPLETE
155 Description: Fix for bug CVE-2012-5611 (bug 67685) is
156 incomplete. The ACL_KEY_LENGTH-sized buffers in acl_get() and
157 check_grant_db() can be overflown by up to two bytes. That's
158 probably not enough to do anything more serious than crashing
159 mysqld.
160 Analysis: In acl_get() when "copy_length" is calculated it
161 just adding the variable lengths. But when we are using them
162 with strmov() we are adding +1 to each. This will lead to a
163 three byte buffer overflow (i.e two +1's at strmov() and one
164 byte for the null added by strmov() function). Similarly it
165 happens for check_grant_db() function as well.
166 Fix: We need to add "+2" to "copy_length" in acl_get()
167 and "+1" to "copy_length" in check_grant_db().
168 ------------------------------------------------------------
169 revno: 4053
170 committer: Nuno Carvalho <nuno.carvalho@oracle.com>
171 branch nick: mysql-5.1
172 timestamp: Mon 2013-10-14 15:45:12 +0100
173 message:
174 WL#7266: Dump-thread additional concurrency tests
176 This worklog aims at testing the two following scenarios:
178 1) Whenever the mysql_binlog_send method (dump thread)
179 reaches the end of file when reading events from the binlog, before
180 checking if it should wait for more events, there was a test to
181 check if the file being read was still active, i.e, it was the last
182 known binlog. However, it was possible that something was written to
183 the binary log and then a rotation would happen, after EOF was
184 detected and before the check for active was performed. In this
185 case, the end of the binary log would not be read by the dump
186 thread, and this would cause the slave to lose updates.
187 This test verifies that the problem has been fixed. It waits during
188 this window while forcing a rotation in the binlog.
190 2) Verify dump thread can send events in active file, correctly after
191 encountering an IO error.
192 ------------------------------------------------------------
193 revno: 4052 [merge]
194 committer: Kent Boortz <kent.boortz@oracle.com>
195 branch nick: mysql-5.1
196 timestamp: Mon 2013-10-07 12:44:38 +0200
197 message:
198 Corrections of copyright headers (RE-request 45781)
199 ------------------------------------------------------------
200 revno: 4050.1.1
201 committer: Kent Boortz <kent.boortz@oracle.com>
202 branch nick: mysql-5.1
203 timestamp: Fri 2013-10-04 13:51:13 +0200
204 message:
205 Corretions of copyright headers (RE-request 45781)
206 ------------------------------------------------------------
207 revno: 4051
208 committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com>
209 branch nick: mysql-5.1
210 timestamp: Mon 2013-10-07 15:16:31 +0900
211 message:
212 Bug#17431533 : FAILING ASSERTION: INDEX->PAGE != 0XFFFFFFFF AFTER DISCARDING TABLESPACE
214 ha_innobase::records_in_range() should return HA_POS_ERROR for the table during discarded without requesting pages.
215 The later other handler method should treat the error correctly.
217 Approved by Sunny in rb#3433
218 ------------------------------------------------------------
219 revno: 4050
220 committer: Satya Bodapati <satya.bodapati@oracle.com>
221 branch nick: mysql-5.1
222 timestamp: Fri 2013-09-27 18:30:46 +0530
223 message:
224 BUG#17446090 - TESTCASE INNODB_BUG16752251.TEST FAILS RANDOMLY ON PB2
226 Enable disabled testcases.
227 ------------------------------------------------------------
228 revno: 4049 [merge]
229 author: hery.ramilison@oracle.com
230 committer: Hery Ramilison <hery.ramilison@oracle.com>
231 branch nick: mysql-5.1
232 timestamp: Fri 2013-09-20 21:08:08 +0200
233 message:
234 Merge from mysql-5.1.72-release
235 ------------------------------------------------------------
236 revno: 4039.1.5
237 tags: mysql-5.1.72
238 committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
239 branch nick: mysql-5.1.72-release
240 timestamp: Mon 2013-09-09 20:07:12 +0200
241 message:
242 Reverted the changes to spec file to ignore mysqld_safe.pid file, updated the logic to get the correct count of PID files