• Sujatha Sivakumar's avatar
    Bug#12818255: READ-ONLY OPTION DOES NOT ALLOW · 818b3a91
    Sujatha Sivakumar authored
    INSERTS/UPDATES ON TEMPORARY TABLES
    Bug#14294223: CHANGES NOT ALLOWED TO TEMPORARY TABLES ON
    READ-ONLY SERVERS
    
    Problem:
    ========
    Running 5.5.14 in read only we can create temporary tables
    but can not insert or update records in the table. When we
    try we get Error 1290 : The MySQL server is running with the
    --read-only option so it cannot execute this statement.
    
    Analysis:
    =========
    This bug is very specific to binlog being enabled and
    binlog-format being stmt/mixed. Standalone server without
    binlog enabled or with row based binlog-mode works fine.
    
    How standalone server and row based replication work:
    =====================================================
    Standalone server and row based replication mark the
    transactions as read_write only when they are modifying
    non temporary tables as part of their current transaction.
    
    Because of this when code enters commit phase it checks
    if a transaction is read_write or not. If the transaction
    is read_write and global read only mode is enabled those
    transaction will fail with 'server is read only mode'
    error.
    
    In the case of statement based mode at the time of writing
    to binary log a binlog handler is created and it is always
    marked as read_write. In case of temporary tables even
    though the engine did not mark the transaction as read_write
    but the new transaction that is started by binlog handler is
    considered as read_write.
    
    Hence in this case when code enters commit phase it finds
    one handler which has a read_write transaction even when
    we are modifying temporary table. This causes the server
    to throw an error when global read-only mode is enabled.
    
    Fix:
    ====
    At the time of commit in "ha_commit_trans" if a read_write
    transaction is found, we should check if this transaction is
    coming from a handler other than binlog_handler. This will
    ensure that there is a genuine read_write transaction being
    sent by the engine apart from binlog_handler and only then
    it should be blocked.
    818b3a91
handler.cc 160 KB