Comment 17 for bug 1729536

Hi,

Thanks for your work on this!

The ideal for upstream is if you can find a self-contained testcase we
can use to reproduce from scratch, i.e. something along the lines of:

* Set up master-slave replication
* Create a table with [columns] and 70k rows
* Run OPTIMIZE TABLE <and whatever other queries> on the master
* Observe crash (not necessarily 100% of the time)

If you can give some information about the table in question and
configuration of master and slave it might also be of help.

--
Lars

On 06. des. 2017 09:15, Eric Fjøsne wrote:
> Dears,
>
> I finally finished narrowing it down to the single request causing the
> crash.
>
> I reactivated the TRUNCATE requests and those are working flawlessly. It
> is an OPTIMIZE TABLE request on a table of about 70000 entries that
> causes the mysql service crash. It might be under use simultaneously,
> but only on the mysql master server, not on the slave where the crash
> occurs.
>
> This OPTIMIZE TABLE gets executed on the master server, then replicated
> on the slave server where it causes a mysql service crash, with the
> backtrace mentioned a few days ago.
>
> What can I do next to further investigate this in order to provide
> feedback over here in an efficient way ?
>
> Thanks in advance for the help,
>
> Eric
>