[MDEV-9551] Can't load common_schema Created: 2016-02-11  Updated: 2016-02-17  Resolved: 2016-02-12

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Procedure
Affects Version/s: 5.5.47
Fix Version/s: 5.5.48

Type: Bug Priority: Major
Reporter: Patryk Pomykalski Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: upstream-fixed


 Description   

Loading common_schema version 2.2 results in error:

ERROR 1644 (91100) at line 12146: QueryScript error: [Unsupported token: "sta"] at 5: "try {
set @common_schema_percona_server_expected := @common_schema_percon

This looks like a bug in SELECT INTO queries. I have pinpointed it to query at line 6063:

SELECT level, token, state FROM _sql_tokens WHERE id = id_from INTO statement_level, first_token, first_state;

This query returns normally:
0 \n whitespace

but the variables get values as if the query returned:
0 sta white



 Comments   
Comment by Patryk Pomykalski [ 2016-02-11 ]

Found in MySQL 5.5.48 changelog:

  • Data corruption or a server exit could occur if a stored procedure had a variable declared as TEXT or BLOB and data was copied to that variable using SELECT ... INTO syntax from a TEXT or BLOB column. (Bug #22203532, Bug #22232332, Bug #21941152)
Comment by Elena Stepanova [ 2016-02-12 ]

Right, the problem gets fixed by this commit:

commit 863f7cebd79e76f90bd8f1e3e0c1a1de5fe77d07 3d1306f7b74077cfa197c8fa23baeb96c535af67
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Fri Jan 8 06:46:59 2016 +0530
 
    Bug #22232332: SAVING TEXT FIELD TO TEXT VARIABLE IN A
                   PROCEDURE RESULTS IN GARBAGE BYTES
    
    Issue:
    -----
    This problem occurs under the following conditions:
    
    a) Stored procedure has a variable is declared as TEXT/BLOB.
    b) Data is copied into the the variable using the
       SELECT...INTO syntax from a TEXT/BLOB column.
    
    Data corruption can occur in such cases.
    
    SOLUTION:
    ---------
    The blob type does not allocate space for the string to be
    stored. Instead it contains a pointer to the source string.
    Since the source is deallocated immediately after the
    select statement, this can cause data corruption.
    
    As part of the fix for Bug #21143080, when the source was
    part of the table's write-set, blob would allocate the
    neccessary space. But this fix missed the possibility that,
    as in the above case, the target might be a variable.
    
    The fix will add the copy_blobs check that was removed by
    the earlier fix.
 

Generated at Thu Feb 08 07:35:31 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.