Merge lp:~gl-az/percona-server/ST-31919-5.5 into lp:percona-server/5.5
Status: | Superseded |
---|---|
Proposed branch: | lp:~gl-az/percona-server/ST-31919-5.5 |
Merge into: | lp:percona-server/5.5 |
Diff against target: |
186 lines (+163/-0) (has conflicts) 3 files modified
Percona-Server/mysql-test/suite/federated/federated_bug_68354.result (+80/-0) Percona-Server/mysql-test/suite/federated/federated_bug_68354.test (+79/-0) Percona-Server/storage/federated/ha_federated.cc (+4/-0) Conflict adding file Percona-Server/mysql-test/suite/federated/federated_bug_68354.result. Moved existing file to Percona-Server/mysql-test/suite/federated/federated_bug_68354.result.moved. Conflict adding file Percona-Server/mysql-test/suite/federated/federated_bug_68354.test. Moved existing file to Percona-Server/mysql-test/suite/federated/federated_bug_68354.test.moved. Text conflict in Percona-Server/storage/federated/ha_federated.cc |
To merge this branch: | bzr merge lp:~gl-az/percona-server/ST-31919-5.5 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alexey Kopytov (community) | Approve | ||
Review via email: mp+170166@code.launchpad.net |
This proposal supersedes a proposal from 2013-06-17.
This proposal has been superseded by a proposal from 2013-06-25.
Description of the change
Fix for upstream 68354 and lp 1182572:
Server crashes on update/join FEDERATED + local table when only 1 local row
This issue seems to be the result of a poor or changed assumption in the order
in which handler calls are made. In this specific scenario (a join with a local
table that has exactly one matching record) there is an assumption in the code
that a call to position will always come after a 'rnd_init/
'rnd_next/
The failing call order is:
ha_federated:
ha_federated:
ha_federated:
ha_federated:
ha_federated:
ha_federated:
ha_federated:
So here you can see position is getting called _outside_ of the scope of an
_init.._end table and/or index scan. This does indicate a change/problem in
the server but that is outside the scope of this fix.
As results are fetched, they are added to an interal list of result sets called
'results'. The last result set/current position is also held in the
'stored_result' value. If 'index_end' or 'rnd_end' is called before 'position'
has been called, the 'stored_result' is zeroed out and that result is removed
from the 'stored_results' list. When 'position' is called, a NULL result is
returned, which is then passed back through 'rnd_pos', which then dereferences
the NULL value and tries to manipulate some of the result internals, crashing.
So seems that the intention of the whole 'stored_result' was to have a place
to track all results allocated for the purposes of keeping them valid for the
'position' and 'rnd_pos' calls.
My approch to fixing this is to restructure this somewhan and instead of
tracking all results allocated in the 'results' list and popping them out when
they are discovered to not be needed, I went the other way. The results only
get addes to a storage list when it has been proven that they are in fact
needed later. So now for each new result set, it is temporarily stored in a
new value called 'last_result'. Whenever a new last_result needs created, it is
set by calling a new function 'set_last_result'. This function will check to
see if 'position' has been called on that result and if so, add it to the
(renamed) list 'stored_results' and clears the 'position_called' flag, else it
will free the 'last_result'. It then sets the new 'last_result' value.
Because of the out of scan scope call of position, we can no longer clear the
'stored_results' lists on '_end'. It will be cleared now when 'reset' is
called.
I have created a test case (suite/
verified that it fails without the fix. Everything tests out under the federated
suite and the issue appears fixed.
The only downside is that a lengthy query could use a lot of memory while
hanging onto old 'position'ed results but I can't see how that can be safely
avoided in this particular handler.
http:// jenkins. percona. com/view/ PS%205. 5/job/percona- server- 5.5-param/ 767/