Bug #49931 Incorrect type in read_log_event error
Submitted: 24 Dec 2009 19:58 Modified: 15 Nov 2010 12:01
Reporter: Andrew Hutchings Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: Daogang Qu CPU Architecture:Any

[24 Dec 2009 19:58] Andrew Hutchings
Description:
In Log_event* Log_event::read_log_event:

    sql_print_error("Error in Log_event::read_log_event(): "
                    "'%s', data_len: %d, event_type: %d",
                    error,data_len,head[EVENT_TYPE_OFFSET]);

data_len is an unsigned int so this should be %u to stop displaying a negative output here, such as:

Error in Log_event::read_log_event(): 'Event too big', data_len: -7362359, event_type: 23

How to repeat:
Code inspection
[8 Feb 2010 9:27] Daogang Qu
Hi Andrew,
How to reproduce the bug? Could you share your test case?
Thanks!
[8 Feb 2010 10:00] Andrew Hutchings
Hello Daogang,

To reproduce you need:
1. to write an RBR event to the binlog > 1GB in size (a huge blob insert for example)
2. read the binlog with mysqlbinlog -v
[8 Feb 2010 10:04] Andrew Hutchings
Sorry, that should be > 2GB to see this problem :)
[18 May 2010 10:09] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/108501

3185 Dao-Gang.Qu@sun.com	2010-05-18
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
      
      The MYSQL server can create a row events with size is bigger than 1GB
      and transmit it successfully. But the slave I/O thread will check the
      size of the event by the value of 'max_allowed_packet' when reading 
      log event from binlog. The slave SQL thread do the same thing. And
      the max value of 'max_allowed_packet' is 1073741824. Once the size
      of a row event is bigger than the max value. It will cause
      'Event too large' or 'packet too large' error.
      
      To fix the problem to replicate a row event with size is more than
      1 GB to slave. The slave I/O thread and slave SQL thread will check
      the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog.
      Then the mysqlbinlog will add a new 'binlog-row-event-max-size'
      option for reading large row event.
     @ client/mysqlbinlog.cc
        Added code to add a new 'binlog-row-event-max-size' mysqlbinlog
        option for reading large row event.
     @ mysql-test/suite/rpl/r/rpl_log_event.result
        Test Result for Bug#49931 and Bug#49932
     @ mysql-test/suite/rpl/t/rpl_log_event.test
        Added test file to verify if the slave I/O thread and slave SQL thread 
        will check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog, and 
        the added 'binlog-row-event-max-size' mysqlbinlog option works fine.
     @ sql/log_event.cc
        Added code to make the slave I/O thread and slave SQL thread will
        check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog.
     @ sql/sql_client.cc
        Added code to make the max_packet_size will take the bigger
        one the 'net_buffer_length', 'max_allowed_packet' and
        'opt_binlog_rows_event_max_size'.
[24 May 2010 5:33] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/108972

3186 Dao-Gang.Qu@sun.com	2010-05-24
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
        
      The MYSQL server can create a row events with size is bigger than 1GB
      and transmit it successfully. But the slave I/O thread will check the
      size of the event by the value of 'max_allowed_packet' when reading 
      log event from binlog. The slave SQL thread do the same thing. And
      the max value of 'max_allowed_packet' is 1073741824. Once the size
      of a row event is bigger than the max value. It will cause
      'Event too large' or 'packet too large' error.
        
      To fix the problem to replicate a row event with size is more than
      1 GB to slave. The slave I/O thread and slave SQL thread will check
      the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog.
      Then the mysqlbinlog will add a new 'binlog-row-event-max-size'
      option for reading large row event.
     @ sql/slave.cc
        Added code to assign the max_packet_size with the bigger one the
        'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that
        replicate large row event with its size is more than 1 GB.
     @ sql/sql_client.cc
        Restore the code
[24 May 2010 6:29] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/108974

3185 Dao-Gang.Qu@sun.com	2010-05-24
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
      
      The MYSQL server can create a row events with size is bigger than 1GB
      and transmit it successfully. But the slave I/O thread will check the
      size of the event by the value of 'max_allowed_packet' when reading 
      log event from binlog. The slave SQL thread do the same thing. And
      the max value of 'max_allowed_packet' is 1073741824. Once the size
      of a row event is bigger than the max value. It will cause
      'Event too large' or 'packet too large' error.
      
      To fix the problem to replicate a row event with size is more than
      1 GB to slave. The slave I/O thread and slave SQL thread will check
      the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog.
      Then the mysqlbinlog will add a new 'binlog-row-event-max-size'
      option for reading large row event.
      ******
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
        
      The MYSQL server can create a row events with size is bigger than 1GB
      and transmit it successfully. But the slave I/O thread will check the
      size of the event by the value of 'max_allowed_packet' when reading 
      log event from binlog. The slave SQL thread do the same thing. And
      the max value of 'max_allowed_packet' is 1073741824. Once the size
      of a row event is bigger than the max value. It will cause
      'Event too large' or 'packet too large' error.
        
      To fix the problem to replicate a row event with size is more than
      1 GB to slave. The slave I/O thread and slave SQL thread will check
      the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog.
      Then the mysqlbinlog will add a new 'binlog-row-event-max-size'
      option for reading large row event.
     @ client/mysqlbinlog.cc
        Added code to add a new 'binlog-row-event-max-size' mysqlbinlog
        option for reading large row event.
     @ mysql-test/suite/rpl/r/rpl_log_event.result
        Test Result for Bug#49931 and Bug#49932
     @ mysql-test/suite/rpl/t/rpl_log_event.test
        Added test file to verify if the slave I/O thread and slave SQL thread 
        will check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog, and 
        the added 'binlog-row-event-max-size' mysqlbinlog option works fine.
     @ sql/log_event.cc
        Added code to make the slave I/O thread and slave SQL thread will
        check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog.
     @ sql/slave.cc
        Added code to assign the max_packet_size with the bigger one the
        'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that
        replicate large row event with its size is more than 1 GB.
[25 May 2010 3:40] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/109110

3185 Dao-Gang.Qu@sun.com	2010-05-25
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
      
      The MYSQL server can create a row events with size is bigger than 1GB
      and transmit it successfully. But the slave I/O thread will check the
      size of the event by the value of 'max_allowed_packet' when reading 
      log event from binlog. The slave SQL thread do the same thing. And
      the max value of 'max_allowed_packet' is 1073741824. Once the size
      of a row event is bigger than the max value. It will cause
      'Event too large' or 'packet too large' error.
      
      To fix the problem to replicate a row event with size is more than
      1 GB to slave. The slave I/O thread and slave SQL thread will check
      the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog.
      Then the mysqlbinlog will add a new 'binlog-row-event-max-size'
      option for reading large row event.
     @ client/mysqlbinlog.cc
        Added code to add a new 'binlog-row-event-max-size' mysqlbinlog
        option for reading large row event.
     @ mysql-test/suite/rpl/r/rpl_log_event.result
        Test Result for Bug#49931 and Bug#49932
     @ mysql-test/suite/rpl/t/rpl_log_event.test
        Added test file to verify if the slave I/O thread and slave SQL thread 
        will check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog, and 
        the added 'binlog-row-event-max-size' mysqlbinlog option works fine.
     @ sql/log_event.cc
        Added code to make the slave I/O thread and slave SQL thread will
        check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog.
     @ sql/slave.cc
        Added code to assign the max_packet_size with the bigger one the
        'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that
        replicate large row event with its size is more than 1 GB.
[25 May 2010 10:05] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/109149

3185 Dao-Gang.Qu@sun.com	2010-05-25
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
      
      The MYSQL server can create a row events with size is bigger than 1GB
      and transmit it successfully. But the slave I/O thread will check the
      size of the event by the value of 'max_allowed_packet' when reading 
      log event from binlog. The slave SQL thread do the same thing. And
      the max value of 'max_allowed_packet' is 1073741824. Once the size
      of a row event is bigger than the max value. It will cause
      'Event too large' or 'packet too large' error.
      
      To fix the problem to replicate a row event with size is more than
      1 GB to slave. The slave I/O thread and slave SQL thread will check
      the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog.
      Then the mysqlbinlog will add a new 'binlog-row-event-max-size'
      option for reading large row event.
     @ client/mysqlbinlog.cc
        Added code to add a new 'binlog-row-event-max-size' mysqlbinlog
        option for reading large row event.
     @ mysql-test/suite/rpl/r/rpl_log_event.result
        Test Result for Bug#49931 and Bug#49932
     @ mysql-test/suite/rpl/t/rpl_log_event.test
        Added test file to verify if the slave I/O thread and slave SQL thread 
        will check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog, and 
        the added 'binlog-row-event-max-size' mysqlbinlog option works fine.
     @ sql/log_event.cc
        Added code to make the slave I/O thread and slave SQL thread will
        check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog.
     @ sql/slave.cc
        Added code to assign the max_packet_size with the bigger one the
        'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that
        replicate large row event with its size is more than 1 GB.
[27 May 2010 8:56] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/109324

3185 Dao-Gang.Qu@sun.com	2010-05-27
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
      
      
      The size limitation of ROW event is controlled by binlog-row-event-max-size (4G),
      which can be larger than max-allowed-packet (1G). And the value of
      max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave
      IO/SQL thread and mysqlbinlog just check the size of the ROW event by
      the value of 'max_allowed_packet' when reading log event from binlog.  
      So it will cause 'Event too large' or 'packet too large' error, if the
      size of ROW event is bigger than the value of 'max_allowed_packet'.
      
      To fix the problem, the slave IO/SQL thread and mysqlbinlog will
      check the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog. 
      And add a new 'binlog-row-event-max-size' (4G by default) option
      to mysqlbinlog. Then mysqlbinlog can read a large ROW event.
     @ client/mysqlbinlog.cc
        Added code to add a new 'binlog-row-event-max-size' mysqlbinlog
        option for reading large row event.
     @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result
        Test Result for Bug#49931 and Bug#49932
     @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test
        Added test file to verify if the slave I/O thread and slave SQL thread 
        will check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog, and 
        the added 'binlog-row-event-max-size' mysqlbinlog option works fine.
     @ sql/log_event.cc
        Added code to make the slave I/O thread and slave SQL thread will
        check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog.
     @ sql/slave.cc
        Added code to assign the max_packet_size with the bigger one the
        'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that
        replicate large row event with its size is more than 1 GB.
[27 May 2010 10:43] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/109341

3185 Dao-Gang.Qu@sun.com	2010-05-27
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
      
      
      The size limitation of ROW event is controlled by binlog-row-event-max-size (4G),
      which can be larger than max-allowed-packet (1G). And the value of
      max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave
      IO/SQL thread and mysqlbinlog just check the size of the ROW event by
      the value of 'max_allowed_packet' when reading log event from binlog.  
      So it will cause 'Event too large' or 'packet too large' error, if the
      size of ROW event is bigger than the value of 'max_allowed_packet'.
      
      To fix the problem, the slave IO/SQL thread and mysqlbinlog will
      check the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog. 
      And add a new 'binlog-row-event-max-size' (4G by default) option
      to mysqlbinlog. Then mysqlbinlog can read a large ROW event.
     @ client/mysqlbinlog.cc
        Added code to add a new 'binlog-row-event-max-size' mysqlbinlog
        option for reading large row event.
     @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result
        Test Result for Bug#49931 and Bug#49932
     @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test
        Added test file to verify if the slave I/O thread and slave SQL thread 
        will check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog, and 
        the added 'binlog-row-event-max-size' mysqlbinlog option works fine.
     @ sql/log_event.cc
        Added code to make the slave I/O thread and slave SQL thread will
        check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog.
     @ sql/slave.cc
        Added code to assign the max_packet_size with the bigger one the
        'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that
        replicate large row event with its size is more than 1 GB.
[1 Jun 2010 7:04] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/109646

3186 Dao-Gang.Qu@sun.com	2010-06-01
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
      
      The size limitation of ROW event is controlled by binlog-row-event-max-size (4G),
      which can be larger than max-allowed-packet (1G). And the value of
      max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave
      IO/SQL thread and mysqlbinlog just check the size of the ROW event by
      the value of 'max_allowed_packet' when reading log event from binlog.  
      So it will cause 'Event too large' or 'packet too large' error, if the
      size of ROW event is bigger than the value of 'max_allowed_packet'.
            
      To fix the problem, the slave IO/SQL thread and mysqlbinlog will
      check the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog. 
      And add a new 'binlog-row-event-max-size' (4G by default) option
      to mysqlbinlog. Then mysqlbinlog can read a large ROW event.
     @ client/mysqlbinlog.cc
        Added code to add a new 'binlog-row-event-max-size' mysqlbinlog
        option for reading large row event.
     @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result
        Test Result for Bug#49931 and Bug#49932.
     @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test
        Added test file to verify if the slave I/O thread and slave SQL thread 
        will check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog, and 
        the added 'binlog-row-event-max-size' mysqlbinlog option works fine.
     @ sql/log_event.cc
        Added code to make the slave I/O thread and slave SQL thread will
        check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog.
     @ sql/slave.cc
        Added code to assign the max_packet_size with the bigger one of the 
        values of 'max_packet_size' and 'opt_binlog_rows_event_max_size'.
        So that slave I/O thread can replicate large row event from master.
[1 Jun 2010 7:10] Daogang Qu
Pushed into mysql-5.1-rep+2.
[1 Jun 2010 9:35] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/109671

3143 Dao-Gang.Qu@sun.com	2010-06-01 [merge]
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
            
      The size limitation of ROW event is controlled by binlog-row-event-max-size (4G),
      which can be larger than max-allowed-packet (1G). And the value of
      max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave
      IO/SQL thread and mysqlbinlog just check the size of the ROW event by
      the value of 'max_allowed_packet' when reading log event from binlog.  
      So it will cause 'Event too large' or 'packet too large' error, if the
      size of ROW event is bigger than the value of 'max_allowed_packet'.
                  
      To fix the problem, the slave IO/SQL thread and mysqlbinlog will
      check the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog. 
      And add a new 'binlog-row-event-max-size' (4G by default) option
      to mysqlbinlog. Then mysqlbinlog can read a large ROW event.
     @ client/mysqlbinlog.cc
        Added code to add a new 'binlog-row-event-max-size' mysqlbinlog
        option for reading large row event.
     @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result
        Test Result for Bug#49931 and Bug#49932.
     @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test
        Added test file to verify if the slave I/O thread and slave SQL thread 
        will check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog, and 
        the added 'binlog-row-event-max-size' mysqlbinlog option works fine.
     @ sql/log_event.cc
        Added code to make the slave I/O thread and slave SQL thread will
        check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog.
     @ sql/slave.cc
        Added code to assign the max_packet_size with the bigger one of the 
        values of 'max_packet_size' and 'opt_binlog_rows_event_max_size'.
        So that slave I/O thread can replicate large row event from master.
[1 Jun 2010 9:53] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/109677

2982 Dao-Gang.Qu@sun.com	2010-06-01 [merge]
      Bug #49931  	Incorrect type in read_log_event error
      Bug #49932  	mysqlbinlog max_allowed_packet hard coded to 1GB
            
      The size limitation of ROW event is controlled by binlog-row-event-max-size (4G),
      which can be larger than max-allowed-packet (1G). And the value of
      max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave
      IO/SQL thread and mysqlbinlog just check the size of the ROW event by
      the value of 'max_allowed_packet' when reading log event from binlog.  
      So it will cause 'Event too large' or 'packet too large' error, if the
      size of ROW event is bigger than the value of 'max_allowed_packet'.
                  
      To fix the problem, the slave IO/SQL thread and mysqlbinlog will
      check the bigger one of the values of 'max_allowed_packet' and
      'binlog-row-event-max-size' when reading log event from binlog. 
      And add a new 'binlog-row-event-max-size' (4G by default) option
      to mysqlbinlog. Then mysqlbinlog can read a large ROW event.
     @ client/mysqlbinlog.cc
        Added code to add a new 'binlog-row-event-max-size' mysqlbinlog
        option for reading large row event.
     @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result
        Test Result for Bug#49931 and Bug#49932.
     @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test
        Added test file to verify if the slave I/O thread and slave SQL thread 
        will check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog, and 
        the added 'binlog-row-event-max-size' mysqlbinlog option works fine.
     @ sql/log_event.cc
        Added code to make the slave I/O thread and slave SQL thread will
        check the bigger one of the values of 'max_allowed_packet' and
        'binlog-row-event-max-size' when reading log event from binlog.
     @ sql/slave.cc
        Added code to assign the max_packet_size with the bigger one of the
        values of 'max_packet_size' and 'opt_binlog_rows_event_max_size'.
        So that slave I/O thread can replicate large row event from master.
[1 Jun 2010 10:04] Daogang Qu
Pushed into mysql-5.1-rep+2, mysql-5.1-rep+3 and mysql-next-mr-rpl-merge.
[26 Jun 2010 7:40] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100626073921-t0e6q2c9nkhuemnj) (version source revid:alik@sun.com-20100626073921-t0e6q2c9nkhuemnj) (pib:16)
[4 Aug 2010 8:02] Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100626073921-t0e6q2c9nkhuemnj) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:19] Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:alik@sun.com-20100626073921-t0e6q2c9nkhuemnj) (merge vers: 5.6.99-m4) (pib:18)
[6 Aug 2010 14:24] Jon Stephens
No changelog entry needed for 5.6, since this did not appear in any 5.6 release.

Waiting for merges to other trees(? -- would help if Version/Target Version fields weren't empty).

Set status = NM.
[16 Aug 2010 6:32] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100816062819-bluwgdq8q4xysmlg) (version source revid:alik@sun.com-20100816062612-enatdwnv809iw3s9) (pib:20)
[3 Sep 2010 17:26] Jon Stephens
I set Need Merge status due to PBKAC -- should have been closed.
[13 Nov 2010 16:21] Bugs System
Pushed into mysql-trunk 5.6.99-m5 (revid:alexander.nozdrin@oracle.com-20101113155825-czmva9kg4n31anmu) (version source revid:vasil.dimov@oracle.com-20100629074804-359l9m9gniauxr94) (merge vers: 5.6.99-m4) (pib:21)
[15 Nov 2010 12:01] Jon Stephens
Closed. See previous comments.