-
Venkatesh Duggirala authored
EXTRA COLUMN ON SLAVE Analysis: In prepare_record(), which is called to prepare the basic record, we call restore_record to fill the tuple with all the default values which are maintained in memory at table->s->default_values. But for the special DEFAULT clauses like DEFAULT CURRENT_TIMESTAMP/NOW(), it is not maintained in table->s->default_values. It will be populated only when we explicit ask to do it (i.e., calling set_default()) function. Fix: For the extra fields that are present only on slave and that does not have 'DEFAULT' clause, replication calls 'set_default()' which will fill the record with default values (like for integer types 'zero' even though there is no DEFAULT 0 for the field). This logic is executed only for the field's that does not have default clause. Now the logic is extended to call set_default when there is special default clause (has_insert_default_function()).
Venkatesh Duggirala authoredEXTRA COLUMN ON SLAVE Analysis: In prepare_record(), which is called to prepare the basic record, we call restore_record to fill the tuple with all the default values which are maintained in memory at table->s->default_values. But for the special DEFAULT clauses like DEFAULT CURRENT_TIMESTAMP/NOW(), it is not maintained in table->s->default_values. It will be populated only when we explicit ask to do it (i.e., calling set_default()) function. Fix: For the extra fields that are present only on slave and that does not have 'DEFAULT' clause, replication calls 'set_default()' which will fill the record with default values (like for integer types 'zero' even though there is no DEFAULT 0 for the field). This logic is executed only for the field's that does not have default clause. Now the logic is extended to call set_default when there is special default clause (has_insert_default_function()).
Loading