multiple field_deleted_data, field_deleted_revision tables in database

I had the same problem. The cron didnt seem to do nothing with my 100 deleted_data and and 100 deleted_revisions tables. Problem with relying on field_purge_batch as part of normal cron execution is that it has lower limit (i think it was 5?). After running purge as separate call with limit of 50 (execution time ~200 secs) and counting all the rows of deleted tables in between, I was able to verify that everything was working. Row count decreased by 5400 on each purge and after awhile even 4 tables got dropped. Now im fairly certain that fields are not hanging for some mystical dependency. Current decision is should i just delete the tables form database and clear the related rows from field_config and field_config_instance or run the purge function repeatedly for 1 day to get rid of all ~1800 000 rows and 100 tables correctly.

Rough code in custom module

<?php
function mymodule_menu() {  
	$items['purge_fields'] = array(
		'page callback' => 'mymodule_run_purge',
		'access arguments' => array('access content'),
	 );
        $items['count_rows'] = array(
		'page callback' => 'mymodule_count_rows',
		'access arguments' => array('access content'),
	 );
	return $items;
}
function mymodule_run_purge(){   
  field_purge_batch(50);
  return '';
}

function mymodule_count_rows(){   
$tables = db_query("select table_name from information_schema.tables where table_name like '%deleted%'")->fetchCol();
  dsm($tables); // prints message with devel module
  $counter=0;
  foreach($tables as $table){
    $rows = db_query("select count(*) from $table")->fetchField();
    $counter = $counter+$rows;
  }
  dsm($counter);
  return '';
}
?>

Those tables will eventually be cleared by field_purge_batch; after about six hours (I think), cron runs will begin clearing out the tables. Things are done this way to avoid causing the actual field deletion operation to take too long.

If you want to clear them out sooner, make sure you delete the table itself, then delete the corresponding (now expired) records from {field_config} and {field_config_instance} (they should be marked with 'deleted' = 0—that's how the field module knows to delete them after a certain amount of time).

Or you could just run cron manually. That took care of it for me.

Don't mean to dig up an old post, but this statement is wrong:

(they should be marked with 'deleted' = 0—that's how the field module knows to delete them after a certain amount of time).

Items awaiting deletion are marked 'deleted'=1.

Running cron wasn't deleting the tables for me. On closer inspection, there was an entry in field_config_instance marked for deletion but I had inadvertently deleted it manually before I had understood this whole process. Removing that entry allowed the purge process to proceed normally. (It was stopping with an exception when it couldn't find the table that was supposed to be there.)