lp:~jaypipes/drizzle/replication-group-commit

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:~drizzle-trunk/drizzle/development

Eric Lambert (community): Approve on 2009-11-03

Diff: 523 lines

12 files modified

drizzled/message/statement_transform.cc (+18/-78)
drizzled/message/statement_transform.h (+0/-26)
drizzled/message/transaction.proto (+3/-2)
drizzled/message/transaction_writer.cc (+3/-4)
drizzled/replication_services.cc (+52/-26)
tests/suite/transaction_log/r/filtered_replicator.result (+21/-0)
tests/suite/transaction_log/r/no_modification.result (+20/-0)
tests/suite/transaction_log/r/update.result (+21/-0)
tests/suite/transaction_log/t/no_modification-master.opt (+1/-0)
tests/suite/transaction_log/t/no_modification.inc (+26/-0)
tests/suite/transaction_log/t/no_modification.test (+13/-0)
tests/suite/transaction_log/t/update.inc (+16/-0)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Bug #440141: Replication: replication generates incorrect update commands when where clause uses a field contained in set clause

Critical

Fix Released

Link a bug report

Related blueprints

1178. By Jay Pipes <jpipes@serialcoder> on 2009-11-06

Adds support for BLOB fields in the replication stream. Note that
this does not yet support extremely large BLOB data. Extremely large
BLOB data will be written to the transaction log in specialized transaction
log entries for that. In this patch, we simply allow the main Transaction
message and the reader/writer programs to work with binary data properly.

Adds a simple test for BLOB fields and the transaction log.
The problem was figuring out how to correctly replace embedded NUL
characters in the output of the transaction reader with \\0 so that
mysqltest.cc wouldn't puke when cat'ing the result of the reading
of the transaction log when BLOB data was contained.

1177. By Jay Pipes <jpipes@serialcoder> on 2009-11-03

Updated filtered_replicator test due to new tests for UPDATE.

1176. By Jay Pipes <jpipes@serialcoder> on 2009-11-03

This patch fixes a bug in the replication service and transaction
proto file that was occurring when an UPDATE statement was SETting
a field to a value by referencing the field itself.

For instance, imagine the following scenario:

CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY, count INT NOT NULL);
INSERT INTO t1 (id, counter) VALUES (1,1),(2,2),(3,3);
UPDATE t1 SET counter = counter + 1 WHERE id IN (1,2);

Previously, the UpdateHeader message contained a single set_value
byte array containing the new value to set the field to. However,
in scenarios such as the above, for each record being updated, the
value that the field would be set to is different. Therefore, this
patch moves the set_value byte array from the UpdateHeader message
into the UpdateRecord message and names it after_value to match the
existing before_value byte array.

This patch adds a test case to the existing update.test case in the
transaction log suite and modifies the statement_transform library to
properly handle the above scenario.

1175. By Jay Pipes <jpipes@serialcoder> on 2009-11-03

Merge trunk

1174. By Jay Pipes <jpipes@serialcoder> on 2009-10-29

Add test case for when a transaction is manually started but no data modification occurs. This happens, for instance, when sysbench runs, and was causing major performance degradation because lots of blank transactions were being written to the transaction log needlessly.

1173. By Jay Pipes <jpipes@serialcoder> on 2009-10-26

Mac doesn't have fdatasync() :( transaction_log.cc now uses mysys/my_sync.cc's my_sync() call to handle this.

1172. By Jay Pipes <jpipes@serialcoder> on 2009-10-26

Added fdatasync() calls to transaction_log.cc. Not sure how nobody caught this :)

1171. By Jay Pipes <jpipes@serialcoder> on 2009-10-26

Moves all calls to replication services' commitNormalTransaction() into the ha_commit_one_phase() block.

1170. By Jay Pipes <jpipes@serialcoder> on 2009-10-23

Corrects problems where REPLACE and INSERT ... ON DUPLICATE KEY UPDATE
were not properly logging the atomic change in server state to the
transaction log.

The problem had to do with the log_row_for_replication() method
not completely understanding whether a call to ha_update_row() had
really been called during a REPLACE or INSERT call.

See my blog entries for an overly-elaborate explanation as to what
was really going on:

http://www.jpipes.com/index.php?/archives/301-Pop-Quiz-What-Does-REPLACE-Do.html
http://www.jpipes.com/index.php?/archives/303-The-Deal-with-REPLACE-..-Or-Is-It-UPDATE.html
http://jpipes.com/index.php?/archives/305-Yet-Another-Post-on-REPLACE.html

Added test cases for REPLACE and INSERT .. ON DUPLICATE KEY UPDATE.

1169. By Jay Pipes <jpipes@serialcoder> on 2009-10-23

Merge trunk