[Bug]:The issue caused by having the same creation execution cycle for all partition schedules in a single database.

[huayumicheng]

ODC version

版本号：4.2.4-1715688910000
Server: 4.2.4-4.2.4_bp2
Release Date: 2024-05-15

OB version

5.7.25-OceanBase-v4.2.1.4

What happened?

The mydb database has three partition tables, tables t1 and t3 are partitioned on a monthly basis, and t2 is partitioned on a daily basis. Partition plans were set for each of the three tables, and the t3 partition plan was finally set. As t3 is partitioned on a monthly basis, the execution cycle of the creation strategy is set to be executed once a month. However, due to the default mechanism of ODC, the time for all three partition plans is set to be executed once a month, which means that the t2 table partitioned on a daily basis cannot add a partition according to the original plan, which may result in the inability to write data normally on a future day. We hope to fix this bug as soon as possible.

--SQL for querying odc_meta information
select
ss.database_name,
pt.table_name,
ss.trigger_config_json,
iu.account_name,
pt.create_time
from
schedule_schedule ss
inner join partitionplan_table pt on ss.id = pt.schedule_id
inner join partitionplan_table_partitionkey ptp on ptp.partitionplan_table_id = pt.id
inner join iam_user iu on ss.creator_id = iu.id
and ss.status='ENABLED';

What did you expect to happen?

Some tables that use partition plans cannot add partitions properly

How can we reproduce it (as minimally and precisely as possible)?

1. Create two partitioned tables, one partitioned by day and the other by month.
2. For the table partitioned by day, set a partition schedule with the creation policy execution cycle set to daily.
3. For the table partitioned by month, set a partition schedule with the creation policy execution cycle set to monthly.
4. If both partition schedules have their creation policy execution cycles set to daily, it will cause the table partitioned by day to fail to add partitions daily as planned.

Anything else we need to know?

No, nothing else.