Dropping a trigger from a TokuDB table that contains non-ascii characters could lead to a crash

Description

gdb:

SQL:

I'm able to reproduce on both debug and release for 8.0.15-5:

error_log output:

Using InnoDB instead of TokuDB table doesn't result in crash.

Environment

None

created by

Smart Checklist

Activity

Show:

Julia Vural March 4, 2025 at 9:03 PM

It appears that this issue is no longer being worked on, so we are closing it for housekeeping purposes. If you believe the issue still exists, please open a new ticket after confirming it's present in the latest release.

Hrvoje Matijakovic March 6, 2019 at 8:54 PM

I've tried with RocksDB and MEMORY as well but it seems only when TokuDB is used crash occurs.

Memory:

George Lorch March 6, 2019 at 8:30 PM
Edited

Actually, this may be another of the variant of DROP TABLE issues where > 1 transactional engine is involved where one supports atomic DDL and one does not.  There is at least one other issue around here somewhere from the initial 8.0 port ( maybe?) that is similar.

George Lorch March 6, 2019 at 8:14 PM

Are you sure this is related to TokuDB?  The call stack indicates that Toku isn't involved at all and that this is in core server rm table code.

Hrvoje Matijakovic March 6, 2019 at 8:07 PM

Can't reproduce on 5.7.25-28:

Won't Do

Details

Assignee

Reporter

Time tracking

1h logged

Components

Priority

Smart Checklist

Created March 6, 2019 at 8:06 PM
Updated March 4, 2025 at 9:03 PM
Resolved March 4, 2025 at 9:03 PM