Bug #19773 Crash when using multi-table updates with federated tables

Description:
The implementations of ha_federated::position() and ha_federarated::rnd_pos() are conceptually wrong and needs to be re-implented.

The idea of ::postition() is that it should return a reference (primary key, cursor position, file position, etc) to a given row so that on can use ::rnd_pos() to retrive the same row again.

The current implementations assumes that the row is in the active result set, but this is not the case and that why we get a crash.

How to repeat:
Save the file federated2.test as t/federated2.test and do:
mysql-test-run --record t/federated2.test

Note that the test result federated2.result doesn not 100 % comply to federated2.test
The reason is that as federated2.test crashed, I was not able to create a correct result file but instead did run the test against a MyISAM table.

The results from the queries should however be correct and should help verify that the federated code is fixed correctly 

Suggested fix:
The code should be fixed in the following way:

- Rewrite ::position() so that if we are doing a table scan, then store the internal position in *ref. If not, then store the primary key in *ref'.  :rnd_pos() should detect what is stored in *pos and use either position or primary key to find the row.

If there is no primary key, don't allow this table to be updated in a multi-table-update.

Test case for bug

Attachment: federated2.test (application/octet-stream, text), 2.42 KiB.

Result set for test case (with MyISAM files instead of federated files)

Attachment: federated2.result (application/octet-stream, text), 1.60 KiB.

Working on a solution for ::position

this is what I have so far. It passes the basic federated test, but still no go on federated2

void ha_federated::position(const byte *record)
{
  DBUG_ENTER("ha_federated::position");
  if (has_a_primary_key)
  {
    DBUG_PRINT("info", ("has_a_primary_key"));
    ref_length= table->key_info[0].key_length;
    key_copy(ref, (byte *)record, table->key_info, ref_length);
  }
  else
  {
    DBUG_PRINT("info", ("has_a_primary_key"));
    ref_length= mean_rec_length;
    memcpy(ref, record, ref_length);
  }
  DBUG_VOID_RETURN;
}

int ha_federated::rnd_pos(byte *buf, byte *pos)
{
  DBUG_ENTER("ha_federated::rnd_pos");

  int result= 0;
  statistic_increment(table->in_use->status_var.ha_read_rnd_count,
                      &LOCK_status);
  if (has_a_primary_key)
    result= index_read_idx(buf, 0, pos, ref_length, HA_READ_KEY_EXACT);
  else
    memcpy(buf, pos, ref_length);
  DBUG_RETURN(result);
}

Further help from Antony has yielded a working solution that I am working on coding. I estimate this to be committed for review in a day.

I have working code that I just need to clean up today and hope to have a commit for review by end of day.

See patch

Review done.
- Some part of patch needs to be moved into 5.1 as this is new optimizations
- A lot of cleanups to do

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/8049

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/8375

Created a new patch based on Patricks patch, but with less overall code changes.
Patrick has the patch and for me it's ok to push that patch.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/8431

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/8628

Noted in 5.0.23 changelog.

Multiple-table updates with FEDERATED tables could cause a server crash.

Ver 5.1.12-beta

Noted in 5.1.12 changelog.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/9144

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/9145