[mythtv-users] Slow MySQL query after delete

[Michael T. Dean]

On 12/05/2007 09:33 AM, Boleslaw Ciesielski wrote:
> Michael T. Dean wrote:
>   
>> However, when deleting multiple recordings at once, the deletions occur
>> sequentially, so when slow deletes are enabled, the first delete request
>> is made, data is removed from the DB, a reschedule is requested, then
>> the 1GB/2min10sec deletion occurs.  If, during that deletion process,
>> another recording is deleted, the DB data deletion and reschedule waith
>> until the first recording is gone.  When the first file's deletion
>> completes, the backend waits another 3 seconds for the frontend to catch
>> up (though by now it surely already has), then removes data from the DB,
>> reschedules, and begins the deletion process.  Any additional deletion
>> requests wait in the queue for their turn to remove DB data, reschedule,
>> then delete.
> Are you sure about this part? Delete from DB has it's own separate lock 
> from the truncate lock. From MainServer::DoDeleteThread():
>
>      deletelock.lock();
>
>      [...]
>
>      DoDeleteInDB(ds);
>
>      if (pginfo->recgroup != "LiveTV")
>          ScheduledRecording::signalChange(0);
>
>      deletelock.unlock();
>
>      if (slowDeletes && fd != -1)
>          TruncateAndClose(pginfo, fd, ds->filename, size);
>
>
> So all the deletes from DB (and unlinks) happen right away and only the 
> slow truncates are delayed, no?

You're right.  There's a separate independent lock for the actual
truncation.

Mike