[MDEV-29829] System versioning does not work with federation-like engines - disable if not supported Created: 2022-10-19 Updated: 2023-11-28 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - Connect, Storage Engine - Federated, Storage Engine - Spider, Versioned Tables |
| Affects Version/s: | 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10 |
| Fix Version/s: | 10.4, 10.5, 10.6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Elena Stepanova | Assignee: | Sergei Golubchik |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
Federated There was the bug report As a comment there suggested the discovery now does not add a system versioning clause to the federated table, so the final topology is local (federated) non-versioned <=> remote (underlying) versioned. But Federated tables are still allowed to be created with an explicit with system versioning clause, and of course they don't work because nothing was fixed in that regard. It's not a weird use case, one might very well want the local table to be system-versioned because only this way the history can be queried. If it isn't supported, it should be disabled explicitly. Connect There is still an open bug MDEV-15968. It cannot work with versioning because it doesn't store microseconds, so everything is history there; and of course just like federated, it doesn't pass over for system_time all clause to the remote, so history querying doesn't work either. Spider There is a new-ish bug MDEV-28413 about versioned partitioned Spider, that's the only one I've found. It seems complicated, in the essence it's all the same – the Spider table cannot be versioned, as it does not query the history (and, depending on the visibility of columns in the underlying table, may even not be able to do normal updates). |