PostgreSQL禁止对已有分区的表执行ALTER TABLE…SET INTERVAL，因分区边界由初始INTERVAL静态推导，修改会导致冲突；必须先清空或分离现有分区才能变更；停用自动分区需设极大INTERVAL（如'1000 years'），不可设0或NULL。
ALTER TABLE … SET INTERVAL 为什么改不了？
直接执行 alter table t set interval '1 day' 报错 error: cannot alter interval partitioning for a table with existing partitions，不是语法错，是 postgresql 的硬限制：只要表里已经有分区，就禁止用 set interval 修改间隔值。
根本原因在于，PostgreSQL 的间隔分区（FOR VALUES FROM ... TO ...）边界是按初始 INTERVAL 推导生成的，运行时不会动态重算。改间隔会导致已有分区边界与新规则冲突，系统拒绝冒险。
- 必须先清空或迁移所有现有分区数据（比如
TRUNCATE或DETACH后删） - 再执行
ALTER TABLE t SET INTERVAL才会成功 - 如果只是想“停用”自动分区，不能设为
0或NULL——INTERVAL不支持零值，也不接受空字符串
停用自动分区的唯一可行方式
PostgreSQL 没有 DISABLE INTERVAL 这种语法。所谓“关闭”，本质是让新插入的数据不再触发自动创建分区，只靠手动管理。
最稳妥的做法是把 INTERVAL 改成一个极大值，使未来几乎不可能触发自动建分区：
ALTER TABLE logs SET INTERVAL '1000 years';
这样后续 INSERT 即使落在当前最大分区之后，也会因距离太远而跳过自动创建（内部判断逻辑基于“是否需新建 *最多一个* 分区”，超范围则放弃）。注意：'1000 years' 是字符串字面量，必须加单引号。
- 别用
'infinity'—— 类型不匹配，报cannot cast type text to interval - 别试图删掉
PARTITION BY RANGE—— 整个分区结构无法降级为普通表 - 如果业务已不再写入，可直接
ALTER TABLE logs NO INHERIT parent_table（如适用），但和INTERVAL无关
更改间隔前必须处理的隐藏依赖
改 INTERVAL 不只是动个参数，它会影响所有基于分区边界的逻辑，尤其是时间窗口查询和分区剪枝。
例如原设 INTERVAL '1 day'，查询 WHERE ts >= '2024-01-01' AND ts 能精准命中 4 个分区；改成 <code>'7 days' 后，同样 SQL 可能只扫描 1 个大分区，或漏掉边界附近的分区，取决于实际数据分布。
- 检查所有使用
pg_partition_tree()或pg_inherits查询分区关系的运维脚本，它们可能硬编码了旧间隔推算逻辑 - 确认备份工具（如
pg_dump --inserts）没对分区名做正则匹配（比如假设分区名含_20240101） -
VACUUM和ANALYZE需要单独跑新分区，旧统计信息不会自动继承
替代方案：用普通 RANGE 分区 + 手动维护
如果频繁需要调整边界节奏，间隔分区反而成了负担。更可控的方式是放弃 SET INTERVAL，改用显式 RANGE 分区 + 定期脚本管理。
例如用 cron 每天凌晨执行：
CREATE TABLE IF NOT EXISTS logs_20240401 PARTITION OF logs FOR VALUES FROM ('2024-04-01') TO ('2024-04-02');好处是边界完全自主，可随时增、删、拆、合；坏处是少了一层自动化，得自己兜底脚本异常。
- 脚本中务必加
IF NOT EXISTS，避免重复建表失败 - 记得给新分区加索引和权限，继承自主表的设置不会自动复制
- 监控
pg_class.relkind = 'r'且父表为logs的分区数，突降可能意味着脚本挂了
真正麻烦的从来不是改一行 SET INTERVAL，而是改完之后，没人再记得那个被跳过的边界计算逻辑藏在哪段凌晨三点跑的清理脚本里。
