oak-online-alter-table stuck in an endless loop

[GoogleCodeExporter]

Here's the relevant output:

-- Connecting to MySQL
-- Table X.X is of engine innodb
-- Checking for UNIQUE columns on X.X, by which to chunk
-- Possible UNIQUE KEY column names in X.X:
-- - id
-- Table X.__oak_X has been created
-- Table X.__oak_X has been altered
-- Checking for UNIQUE columns on X.__oak_X, by which to chunk
-- Possible UNIQUE KEY column names in X.__oak_notes:
-- - id
-- Checking for UNIQUE columns on X.X, by which to chunk
-- - Found following possible unique keys:
-- - id (int)
-- Chosen unique key is 'id'
-- Shared columns: a, b, c, d, e, f, g, h, i, j, k, id, l, m
-- Created AD trigger
-- Created AU trigger
-- Created AI trigger
-- Attempting to lock tables

-- Tables locked WRITE
-- id (min, max) values: ([1L], [1376476L])
-- Tables unlocked
-- Copying range (1), (1134), progress: 0%
...
-- Copying range (1376475), (1376475), progress: 100%
-- Copying range (1376475), (1376475), progress: 100%
-- Copying range (1376475), (1376475), progress: 100%
-- Copying range (1376475), (1376475), progress: 100%
-- Copying range (1376475), (1376475), progress: 100%
-- Copying range (1376475), (1376475), progress: 100%
-- Copying range (1376475), (1376475), progress: 100%

At that point I aborted the operation after a minute or so of it not doing 
anything useful.

What version of the product are you using? On what operating system?

openarkkit: latest at the time of writing, 180
OS: Ubuntu 10.04.1 LTS
Server version: 5.1.66-0ubuntu0.10.04.1-log (Ubuntu)

I'm starting to work on reproducing/debugging it, but this output may be 
sufficient for someone who knows this code.

Original issue reported on code.google.com by gryw...@gmail.com on 10 Jan 2013 at 1:23

[GoogleCodeExporter]

To reproduce:

- create a table with a PK
- fill it with enough data to make oak-online-alter-tabe run for a reasonable 
time (say, 1 min) to make triggering a race condition easy
- while migration is running, do: delete from your_table where id = (select 
max(id) from your_table)

At this stage table copy will never end. Proposed patch attached.

Original comment by gryw...@gmail.com on 10 Jan 2013 at 6:15

Attachments:

• patch

[GoogleCodeExporter]

Thank you, I will incorporate this into the code

Original comment by shlomi.n...@gmail.com on 13 Jan 2013 at 6:01

• Changed state: Accepted

[GoogleCodeExporter]

This issue was closed by revision r190.

Original comment by shlomi.n...@gmail.com on 13 Jan 2013 at 11:04

• Changed state: Fixed

[GoogleCodeExporter]

On a 2nd thought, this causes a problem when running with --chunk-size=1 (table 
truncated). Chunk size == 1 would be a strange choice anyway and perhaps it 
should simply be checked to be > 1 rather than > 0?

Original comment by gryw...@gmail.com on 16 Jan 2013 at 11:53

[GoogleCodeExporter]

chunk-size=1 is indeed not only strange, not only impractical, but also 
non-functional. I should probably limit to some 100 rows at minimum. Feel free 
to ignore the possibility of chunk-size=1.

Original comment by shlomi.n...@gmail.com on 16 Jan 2013 at 12:35

[GoogleCodeExporter]

The attached patch makes 100 the minimum accepted chunk size.

Original comment by gryw...@gmail.com on 2 Feb 2013 at 8:24

Attachments:

• chunk_size_limit.patch