Bug #101367 Error code not get handled
Submitted: 29 Oct 2020 7:34 Modified: 30 Oct 2020 21:11
Reporter: Li Zhong Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server Severity:S3 (Non-critical)
Version:8.0 OS:Any
Assigned to: CPU Architecture:Any

[29 Oct 2020 7:34] Li Zhong
In storage/innobase/fts/fts0fts.cc, fts_drop_index(), err get return value from fts_empty_common_tables() in line 738:
738   err = fts_empty_common_tables(trx, table);
739   ut_ad(err == DB_SUCCESS);

Although there is a debug assertion following it, it still possible that fts_empty_common_tables() return error code in some cases in non-debug run.

So I wonder whether it’s necessary to write:

return (err);

instead of neglecting it and just going on.

How to repeat:
In source code of mysql-8.0.21
[29 Oct 2020 13:02] MySQL Verification Team
Hi Mr. Zhong,

Thank you for your bug report.

However, this is not a bug.

We uses assert's in our code to stop immediately execution in order to prevent the corruption of data, either in memory or on disk or both. Hence, there are not returns from such errors.

Not a bug.
[29 Oct 2020 17:05] Li Zhong
Thanks for you reply!
However, when compiling source code in non-debug mode, this DEBUG ASSERT will not be included (which can be repeated when using Clang-10.0.0 to compile from source code). 
In this case, the error will be neglect.
[30 Oct 2020 12:43] MySQL Verification Team
Yes, that is exactly our intention.

Those debug asserts are for the internal tests.
[30 Oct 2020 21:11] Li Zhong
In that case, if you run this part of code, the error code will be ignored without any assertion to interrupt it from the corruption of data, either in memory or on disk. Would that cause a error?
[2 Nov 2020 12:29] MySQL Verification Team
No, it would not.