BUG#12969301 : mysql_plugin: enable is ignored if plugin exists

This patch changes the mechanism by which the client enables a 
plugin. Instead of using INSERT IGNORE to reload a plugin library,
it now uses REPLACE INTO. This allows users to load a library
multiple times replacing the existing values in the mysql.plugin
table. This allows users to replace the symbol reference to a
different dl name in the table. Thus permitting enabling of 
multiple versions of the same library without first disabling
the old version.

A regression test was added to ensure this feature works.

--BZR--
revision-id: chuck.bell@oracle.com-20111215211648-qffrge9yc8oh7otg
property-branch-nick: mysql-12969301
testament3-sha1: 48f55590858f3c62be5da39949f1cd0994414a04
Raise version number after cloning 5.0.95
--BZR--
revision-id: mysql-re_ww@oracle.com-20111216112247-om6vpq6xpjcdiejx
property-authors: joerg.bruehe@oracle.com
property-branch-nick: mysql-5.0-security
testament3-sha1: 4bde38365d4095133f8e1d5fd7d9462f35f52f3a
Raise version number after cloning 5.1.61
--BZR--
revision-id: mysql-re_ww@oracle.com-20111216112405-admzozqokred6m6z
property-authors: joerg.bruehe@oracle.com
property-branch-nick: mysql-5.1-security
testament3-sha1: 9e1d468f2735e6c4d1d9c4d1ce60c543f88a449d
Empty merge of version number changes.

--BZR--
revision-id: joerg.bruehe@oracle.com-20111216115007-i6rz7p0ov9j3tn5p
property-branch-nick: security-5.1
testament3-sha1: add46d511ecb996c78c896c6748c4d84fd32fb08
Empty merge of identical version number changes.

--BZR--
revision-id: joerg.bruehe@oracle.com-20111216115147-c1pdonxe82lpuf61
property-branch-nick: security-5.0
testament3-sha1: 1d95d667780a304bcb84a0d75bfe22c564c0d926
Empty merge (alignment of version number changesets).

--BZR--
revision-id: joerg.bruehe@oracle.com-20111216115428-le4i1z5lymvchekh
property-branch-nick: security-5.1
testament3-sha1: d90a6ba0baa38afc087d78c0ddc5e67084fd05c3
Raise version number after cloning 5.5.20
--BZR--
revision-id: joerg.bruehe@oracle.com-20111216184258-4fw1xsw075cwhl5m
property-branch-nick: security-5.5
testament3-sha1: e5c9ebaf9f30194a0506bcdbbfb10ae9789c22b4
Empty upmerge of 5.0 and 5.1 version number increases, also from main 5.5
--BZR--
revision-id: joerg.bruehe@oracle.com-20111216185427-mohda0n227jf87ee
property-branch-nick: security-5.5
testament3-sha1: 83dcce2c74f7fd816a89b8cf2f020d80907790b0
Fix Bug#13510739 63775: SERVER CRASH ON HANDLER READ NEXT AFTER DELETE RECORD.

CREATE TABLE bug13510739 (c INTEGER NOT NULL, PRIMARY KEY (c)) ENGINE=INNODB;
INSERT INTO bug13510739 VALUES (1), (2), (3), (4);
DELETE FROM bug13510739 WHERE c=2;
HANDLER bug13510739 OPEN;
HANDLER bug13510739 READ `primary` = (2);
HANDLER bug13510739 READ `primary` NEXT;  <-- crash

The bug is that in the particular testcase row_search_for_mysql() picked up
a delete-marked record and quit, leaving the cursor non-positioned state and
on the subsequent 'get next' call the code crashed because of the
non-positioned cursor.

In row0sel.cc (line numbers from mysql-trunk):

4653         if (rec_get_deleted_flag(rec, comp)) {
...
4679                 if (index == clust_index && unique_search) {
4680 
4681                         err = DB_RECORD_NOT_FOUND;
4682                         
4683                         goto normal_return;
4684                 }       

it quit from here, not storing the cursor position.

In contrast, if the record=2 is not found at all (e.g. sleep(1) after DELETE
to let the purge wipe it away completely) then 'get = 2' does find record=3
and quits from here:

4366                 if (0 != cmp_dtuple_rec(search_tuple, rec, offsets)) {
...
4394                         btr_pcur_store_position(pcur, &mtr);
4395 
4396                         err = DB_RECORD_NOT_FOUND;
4397 #if 0
4398                         ut_print_name(stderr, trx, FALSE, index->name);
4399                         fputs(" record not found 3\n", stderr);
4400 #endif
4401 
4402                         goto normal_return;

Another fix could be to extend the condition on line 4366 to hold only if
seach_tuple matches rec AND if rec is not delete marked.

Notice that in the above test case if we wait about 1 second somewhere after
DELETE and before 'get = 2', then the testcase does not crash and returns 4
instead. Not sure if this is the correct behavior, but this bugfix removes
the crash and makes the code return what it also returns in the non-crashing
case (if rec=2 is not found during 'get = 2', e.g. we have sleep(1) there).

Approved by:	Marko (http://bur03.no.oracle.com/rb/r/863/)

--BZR--
revision-id: vasil.dimov@oracle.com-20111222105544-6ohjknl6xubi4v6s
property-branch-nick: mysql-5.1-security
testament3-sha1: d6e52b6d4ee7641fb55fcee3467b4177778a7df7
Merge mysql-5.1-security -> mysql-5.5-security

--BZR--
revision-id: vasil.dimov@oracle.com-20111222110533-osvw3zw9ijzuxuqa
property-branch-nick: mysql-5.5-security
testament3-sha1: 8bf6fc4e974e241130717fb59a1de70f1bf42e3d
Backport from mysql-trunk of:
------------------------------------------------------------
revno: 3258
committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
branch nick: mysql-trunk-bug12663165
timestamp: Thu 2011-07-14 10:05:12 +0200
message:
  Bug#12663165 SP DEAD CODE REMOVAL DOESN'T UNDERSTAND CONTINUE HANDLERS
  
  When stored routines are loaded, a simple optimizer tries to locate
  and remove dead code. The problem was that this dead code removal
  did not work correctly with CONTINUE handlers.
  
  If a statement triggers a CONTINUE handler, the following statement
  will be executed after the handler statement has completed. This
  means that the following statement is not dead code even if the
  previous statement unconditionally alters control flow. This fact
  was lost on the dead code removal routine, which ended up with
  removing instructions that could have been executed. This could
  then lead to assertions, crashes and generally bad behavior when
  the stored routine was executed.
  
  This patch fixes the problem by marking as live code all stored
  routine instructions that are in the same scope as a CONTINUE handler.
  
  Test case added to sp.test.

--BZR--
revision-id: jon.hauglid@oracle.com-20120109102802-7e3pvo7uypiult5h
property-branch-nick: mysql-5.1-security
testament3-sha1: 181eec61f5fbe574b526fa7b0ac3cb6f3ac096bf
Merge from mysql-5.1-security to mysql-5.5-security
Text conflict in sql/sql_yacc.yy

--BZR--
revision-id: jon.hauglid@oracle.com-20120109103326-3bvwvppl3vx63jqc
property-branch-nick: mysql-5.5-security
testament3-sha1: e630d5efc716c7dbc8c0dbecf7e877ebe0cf3dfc
empty weave merge from mysql-5.0

--BZR--
revision-id: georgi.kodinov@oracle.com-20120112143944-3d2az1ood029kjt1
property-branch-nick: merge-5.0-security
testament3-sha1: 74d6505db8e5d1fb416e19af19d7f29855fe4e32
weave merge mysql-5.1->mysql-5.1-security

--BZR--
revision-id: georgi.kodinov@oracle.com-20120112144223-kvp7u8tm3cqhw4sp
property-branch-nick: merge-5.1-security
testament3-sha1: 7a84419e42c1fb298110985f0ede31711a0132eb
empty weave merge mysql-5.0-security->mysql-5.1-security

--BZR--
revision-id: georgi.kodinov@oracle.com-20120112144341-gq5m7yadltpy4m2y
property-branch-nick: merge-5.1-security
testament3-sha1: 234a65edb03f6a040348967943f1161b44f38845
weave merge mysql-5.5->mysql-5.5-security

--BZR--
revision-id: georgi.kodinov@oracle.com-20120112144437-fhsucrcwkx020vip
property-branch-nick: merge-5.5-security
testament3-sha1: 331ad95492d75eb48fc2c54ac8d9778952d961c6
empty weave merge mysql-5.1-security->mysql-5.5-security

--BZR--
revision-id: georgi.kodinov@oracle.com-20120112145239-06tk5639mjc7mcid
property-branch-nick: merge-5.5-security
testament3-sha1: 26bf864fcf40785625397ddf10f3597bbfff1f7c
Compile fix needed for AIX,
to work around the lack of a bzero() prototype.
--BZR--
revision-id: joerg.bruehe@oracle.com-20120119160547-as5bq8m604ee3nfg
property-branch-nick: bzero-5.1
property-file-info: ld7:file_id63:sp1f-m_string.h-19700101030959-rraattbvw5ffkokv4sixxf3s7brqqaga7:message390:AIX does have bzero() in its system libraries,
property-file-info: and the configure phase detects it, including the prototype
property-file-info: (sets both HAVE_BZERO and HAVE_DECL_BZERO),
property-file-info: but the declaration is missing when the source is compiled.
property-file-info: Several attempts all failed.
property-file-info: This patch takes the brute force approach to always map
property-file-info: "bzero()" to "memset()" on AIX,
property-file-info: like is done on platforms where "bzero()" is not found at all.4:path18:include/m_string.hee
testament3-sha1: d52870e3918cbe49caabed5c6aec0b0286f7c673
Bug#13580775 ASSERTION FAILED: RECORD_LENGTH == M_RECORD_LENGTH
Bug#13011410 CRASH IN FILESORT CODE WITH GROUP BY/ROLLUP

The assert in 13580775 is visible in 5.6 only, 
but shows that all versions are vulnerable.
13011410 crashes in all versions.

filesort tries to re-use the sort buffer between invocations in order to save
malloc/free overhead.
The fix for Bug 11748783 - 37359: FILESORT CAN BE MORE EFFICIENT.
added an assert that buffer properties (num_records, record_length) are
consistent between invocations. Indeed, they are not necessarily consistent.
  
Fix: re-allocate the sort buffer if properties change.

--BZR--
revision-id: tor.didriksen@oracle.com-20120127101313-q1cljokl8degh6bd
property-branch-nick: 5.1-security
property-file-info: ld7:file_id69:sp1f-partition.result-20050718113029-xlmjyugiq5h2b5wjp236ipsmkmej7i627:message11:New tests.
property-file-info: 4:path29:mysql-test/r/partition.resulted7:file_id67:sp1f-partition.test-20050718113034-pbo3ht3bf4gfa3mz44on3sqafyctwo357:message10:New tests.4:path27:mysql-test/t/partition.tested7:file_id64:sp1f-filesort.cc-19700101030959-mfm2vmdgqqru7emm2meeecleb2q3zdso7:message123:If we already have allocated a sort buffer in a previous execution,
property-file-info: then verify that it is big enough for the current one.
property-file-info: 4:path15:sql/filesort.cced7:file_id60:sp1f-table.h-19700101030959-dv72bajftxj5fbdjuajquappanuv2ija7:message72:Add sort_keys_size; Number of bytes allocated for the sort_keys buffer.
property-file-info: 4:path11:sql/table.hee
testament3-sha1: c0b4e75cbee003b6ce6faf3de2b8ced6ffdee591
Merge 5.1-security => 5.5-security

--BZR--
revision-id: tor.didriksen@oracle.com-20120127122121-27jn2tsiwz6vygu3
property-branch-nick: 5.5-security
testament3-sha1: 969c2892db7f9a0bf1a968c3ee70488ed1fc3fcd