Details
-
Bug
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.3(EOL)
-
None
Description
Update documentation for SYSTEM_TIME partitioning according to the following limitations:
MDEV-28411 LIMIT partition switching doesn't work until the end of statement
MDEV-28459 LIMIT partition switching is not correct in parallel threads
Clarify when and how the last history partition is reorganized:
If the data is partitioned by INTERVAL and there was a chance for the last history partition to overflow before ADD PARTITION: i.e. query timestamp of ADD PARTITION > max timestamp last history partition can hold, the last history partition is reorganized. That means all the records from the last history partition with timestamps that don't fit to that partition are moved to newly added partition. Older history partitions are untouched. Auto-create feature does not do this reorganize.
During the reorganize the table is kept under read-only lock (MDL_SHARED_NO_WRITE). That means you can read the table and you will find all the rows where they were before ALTER.
For partition substitution stage of reorganize MDL_EXCLUSIVE lock is taken and reorganized history partition as well as newly added one take place in the table. During that process you can not read nor write the table, but the time period is relatively short. When the ALTER TABLE finishes MDL_EXCLUSIVE lock is released.
Attachments
Issue Links
- relates to
-
MDEV-20077 Warning on full history partition is delayed until next DML statement
- Closed
-
MDEV-28411 LIMIT partition switching doesn't work until the end of statement
- Open
-
MDEV-17554 Auto-create history partitions for system-versioned tables
- Closed