[MDEV-27618] Atomic DDL is not very atomic on partitioned tables Created: 2022-01-25 Updated: 2023-08-11 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Data Definition - Alter Table, Partitioning |
| Affects Version/s: | 10.6, 10.9, 10.10, 10.11, 11.0, 11.1 |
| Fix Version/s: | 11.1 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Elena Stepanova | Assignee: | Michael Widenius |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | recovery | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Description |
|
Note: To repeat what was also said in the comments, it was already known at the time of atomic DDL development/release ( The test case is non-deterministic, run with --repeat=N. It usually fails for me within several attempts (takes longer on non-debug builds), but it can vary on different machines and builds.
When it doesn't fail right away, it can also leave a temporary .par file behind
|
| Comments |
| Comment by Marko Mäkelä [ 2022-01-25 ] |
|
Like I noted in MDEV-22168, I believe that when the native InnoDB ALTER TABLE is being used (explicit ALGORITHM=INPLACE is not refused), the InnoDB side should be atomic. But, the SQL layer (.par or .frm files) could very well get out of sync with the storage engine. I vaguely remember that partitioning was not exhaustively tested during |
| Comment by Elena Stepanova [ 2022-01-25 ] |
|
Yes, I remember that as well, but I was also told to register encountered partitioning-related issues anyway, and if there is enough information to look at, they will be at least analyzed, with moderate priority. Hence the minor Jira entry. |