Drizzle

Transaction log: Delete on a table without primary key produces insufficient info

Bug #494944 reported by Jobin Augustine on 2009-12-10

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Drizzle	Fix Released	Critical	Jay Pipes	Drizzle bell "bell"

Bug Description

Replication steps:
create table emp (nm varchar(30),id integer);
insert into emp values ('jobin',1);
insert into emp values ('honey',2);
insert into emp values ('kunju',3);
delete from emp where id>1;

produced output:
trx: transaction_context {
  server_id: 1
  transaction_id: 17
  start_timestamp: 1260456288382463
  end_timestamp: 1260456288581486
}
statement {
  type: DELETE
  start_timestamp: 1260456288382466
  end_timestamp: 1260456288581484
  delete_header {
    table_metadata {
      schema_name: "test"
      table_name: "emp"
    }
  }
  delete_data {
    segment_id: 1
    end_segment: true
    record {
    }
    record {
    }
  }
}

Related branches

lp://staging/~jaypipes/drizzle/transaction_log

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

Brian Aker: Pending requested 2009-12-23

Drizzle Developers: Pending requested 2009-12-23

Revision history for this message

Joe Daly (skinny.moey) wrote on 2009-12-10:

This looks to be one of the limitations since the table does not have a primary key on it. Currently no error is thrown. Bug 479743 has some more discussion on it.

Revision history for this message

Jobin Augustine (jobinau) wrote on 2009-12-11:

Thank you Joe,

yes it looks like the limitation as described in discussion related to Bug 479743.
it is very difficult to handle the situation where table don't have primary key.

But there were few ideas floating around transaction log because it be used more generic way.. for example backup for point-in-time recovery.
i don't know this limitation will impose a restriction on that.
whether those ideas will survive any more? :(
Joe, do you know any discussion happened towards this direction?

But at the sametime, as Jay pointed out in the discussion, a table wiithout primary key is meaningless.
(it don't have a theoretical validity).
Probably using this justification we have to enforce the primary key

Thank you,
Jobin.

Revision history for this message

Jay Pipes (jaypipes) wrote on 2009-12-11:

OK, so basically yes, replication does not support tables without primary keys. However, this is still a bug because there should be an error if an insert is attempted into a table which does not have a primary key.

I have pushed a fix and a new test case to my transaction_log branch. If you have a chance, take a look at the no_primary_key test case in plugins/transaction_log/tests/ and let me know if this new error-out behaviour is OK.

Cheers!

Jay

Changed in drizzle:
status:	New → Confirmed
importance:	Undecided → Critical
assignee:	nobody → Jay Pipes (jaypipes)
milestone:	none → bell
status:	Confirmed → Fix Committed

Revision history for this message

Jobin Augustine (jobinau) wrote on 2009-12-12:

Thank you Jay,
Sure..my help will be there to get your kid (transaction log) mature :)

Thank you once again for clarifying and fixing.
Jobin.

Jay Pipes (jaypipes) on 2009-12-23

Changed in drizzle:
status:	Fix Committed → Fix Released

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.