In the provided test case, REMOVE PARTITIONING is run in parallel with OPTIMIZE PARTITION. On master, OPTIMIZE partition starts first and doesn't cause an error, but in the binary log it is written after REMOVE PARTITIONING, and it makes SQL slave thread abort with ER_PARTITION_MGMT_ON_NONPARTITIONED.

It's only reproducible with InnoDB tables, so it might be related to optimize not being supported and executed as recreate + analyze instead:

CREATE TABLE t (a INT) ENGINE = InnoDB PARTITION BY HASH (a) PARTITIONS 4;
ALTER TABLE t OPTIMIZE PARTITION p1;
ALTER TABLE t REMOVE PARTITIONING;
Table Op Msg_type Msg_text
test.t optimize note Table does not support optimize, doing recreate + analyze instead
test.t optimize status OK

master-bin.000001 4 Format_desc 1 106 Server ver: 5.1.60-MariaDB-log, Binlog ver: 4
master-bin.000001 106 Query 1 242 use `test`; CREATE TABLE t (a INT) ENGINE = InnoDB PARTITION BY HASH (a) PARTITIONS 4
master-bin.000001 242 Query 1 338 use `test`; ALTER TABLE t REMOVE PARTITIONING
master-bin.000001 338 Query 1 436 use `test`; ALTER TABLE t OPTIMIZE PARTITION p1

Last_SQL_Error Error 'Partition management on a not partitioned table is not possible' on query. Default database: 'test'. Query: 'ALTER TABLE t OPTIMIZE PARTITION p1'

Affects 5.1, 5.2, 5.3, 5.5.

Also reproducible on MySQL 5.1.60, 5.5.20, 5.6.4 and filed as http://bugs.mysql.com/bug.php?id=64041.

Test case:

--source include/have_innodb.inc
--source include/master-slave.inc
CREATE TABLE t (a INT) ENGINE = InnoDB PARTITION BY HASH (a) PARTITIONS 4;
--connection master1
--send
ALTER TABLE t OPTIMIZE PARTITION p1;
--connection master
ALTER TABLE t REMOVE PARTITIONING;
--connection master1
--reap
--sync_slave_with_master