Details
Major Description
Weired behavior occured which lock situation from 10.11.11.
What should be a solution or next further step about below sypmptom.
- Before 10.11.11, no issue. same simple INSERT INTO ON UPDATE query in Stored procedure.
- Within the stored procedure there are
> insert into _the_temp_table select something from main_real_table
> insert into main_real_table select from _the_temp_table on key duplicated update ....
> at this point, if select two or more rows from _the_temp_table, `Warning: (1048) Column 'xxxxxxx' cannot be null` for all columns
> In the first place, _the_temp_table have fully filled values even 0(zero). Non of null allowed.
> no tracaction settup, single transaction, split transaction setup shows same result by manual execution from mariadb console/command line, heidlasql, any, same.
> Single row working perfect. two or more rows make the error under the same queries/SP.
From an internet articles, someone say DRY/SRT matter make the same issue.
But as I explain above you, that is not same table.(to me. Am I something wrong?)
To resolve what should I do? Config check? Optimizer adjust?(then how?)
Any advice needed.
Attachments
Issue Links
- duplicates
-
MDEV-36026 Problem with INSERT SELECT on NOT NULL columns while having BEFORE UPDATE trigger
-
- Closed
-
Activity
@Elena Stepanova
Yes it is.
When you mention a 'trigger' the error would made from changed loggic that connected to a trigger?
If you have a trigger on the table, it is likely the bug MDEV-36026 . The fix will be released with the next release.
@Elena Stepanova
Confirmed that duplicated issue that you point out.
Sigh, what should I do then.
Don't you guys make a kind of emerggency release?
Can't do this with the version 10.11.11.
Entire transaction ruined and ruining.
What do you guys gonna say? rollback db? or new urgent release?
The possibilities are being evaluated.
Of course, if your production instance activities are badly affected, you can't wait for the re-release to happen, so I suppose the only viable option in this case at the moment is to roll back to the previous release temporarily.
We apologize for the trouble.
Yeah. I did that just replace the 'bin' folder only as quick and dirty job since same 10.11.xx series.
Simple was that but cry call. T.T...
Cheers.
Do you have triggers on the "main_real_table"?