[MDEV-22604] INSERT DELAYED treated as usual INSERT if table has check constraints Created: 2020-05-17 Updated: 2020-05-19 Resolved: 2020-05-19 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Data Manipulation - Insert, Documentation |
| Affects Version/s: | 10.2, 10.3, 10.4, 10.5 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Minor |
| Reporter: | Elena Stepanova | Assignee: | Ian Gilfillan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
INSERT DELAYED above results in the error:
It shouldn't be happening if it is treated as INSERT DELAYED. If we remove CHECK from the table definition, INSERT DELAYED doesn't return the error. The fact that DELAYED is ignored can also be observed in a more intuitive situation, if you lock the table in another client connection. Naturally INSERT DELAYED should return immediately, but with CHECK on the table it doesn't. Reproducible with table-level and column-level check constraints, on 10.2-10.5. Note: |
| Comments |
| Comment by Elena Stepanova [ 2020-05-17 ] |
|
As a consequence, INSERT DELAYED does not work for tables with implicit check constraints, e.g. for application period tables. |
| Comment by Sergei Golubchik [ 2020-05-18 ] |
|
This is intentional. There are many preconditions for INSERT DELAYED to work, if they aren't met it's converted to a normal INSERT. CHECK constraints, triggers, skip-new mode, max_insert_delayed_threads == 0, stored functions, replication, etc. |
| Comment by Ian Gilfillan [ 2020-05-19 ] |
|
Added to the list of limitations on the page |