7 Dec
2018
7 Dec
'18
5:03 p.m.
andrei.elkin@pp.inet.fi writes:
Note that the cleanup happens asynchroneously, and system load can cause the cleanup step to be delayed or
even skipped completely in rare cases;
I only can think of crashes here... Anything else do you mean?
There is a small race in the code where the slave background thread can miss a notification to delete rows (this avoids a mutex). Not sure if this is only theoretical. If it should happen, the rows will be deleted in the next batch, so the table would temporarily grow to twice the @@gtid_cleanup_batch_size number of rows. - Kristian.