TimescaleDB 2.28.2 发布：修复迁移与稀疏索引问题，建议尽快升级

预计阅读时间：7 分钟

TimescaleDB 2.28.2 是一个偏向“止血”的小版本：它修复了 2.28.1 之后暴露出来的几个缺陷，官方建议用户尽快升级。对生产环境来说，这类版本通常不带来新特性惊喜，但会影响升级链路、后台任务历史、chunk 约束迁移以及部分索引行为，值得认真安排窗口验证。

这次修了什么

本次发布的重点修复包括：

修复 bgw_job_stat_history 的迁移问题。
修复 chunk_constraint 迁移问题。
修复基于 first/last 的稀疏索引列排序问题。
升级时自动删除不兼容的 smallint bloom filters。

这些名字看起来都偏内部，但影响并不“内部”。例如，后台任务统计历史迁移失败，可能让升级过程卡住；chunk constraint 迁移问题可能影响 hypertable 分块元数据；稀疏索引列排序问题则可能影响某些查询路径的正确性或性能表现。

如果你现在已经在 2.28.1，2.28.2 更像是一个应该尽快合入的补丁版本，而不是“等下个大版本再说”的更新。

升级前先确认当前环境

升级 TimescaleDB 时要区分两个层面：

操作系统或容器里的 TimescaleDB 扩展二进制版本。
PostgreSQL 数据库内部启用的 extension 版本。

二进制包升级完，不代表数据库里的扩展已经升级。建议先在目标数据库里确认当前版本：

SELECT extname, extversion
FROM pg_extension
WHERE extname = 'timescaledb';

也可以检查 PostgreSQL 实际加载到的扩展版本信息：

SELECT default_version, installed_version
FROM pg_available_extensions
WHERE name = 'timescaledb';

如果 default_version 已经是 2.28.2，但 installed_version 仍是旧版本，说明系统包或镜像已经更新，但数据库内 extension 还没有执行升级。

可以这样实践：一个保守升级流程

下面的命令是一个可改造的升级检查脚本，适合放进发布窗口前的 runbook。运行前请把 DB_URL 替换成你的 PostgreSQL 连接串。

#!/usr/bin/env bash
set -euo pipefail

: "${DB_URL:?Please set DB_URL, for example: postgresql://user:pass@localhost:5432/dbname}"

echo "== Current TimescaleDB extension version =="
psql "$DB_URL" -v ON_ERROR_STOP=1 -c "
SELECT extname, extversion
FROM pg_extension
WHERE extname = 'timescaledb';
"

echo "== Available TimescaleDB versions =="
psql "$DB_URL" -v ON_ERROR_STOP=1 -c "
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE name = 'timescaledb';
"

echo "== Upgrade extension inside database =="
psql "$DB_URL" -v ON_ERROR_STOP=1 -c "ALTER EXTENSION timescaledb UPDATE;"

echo "== Version after upgrade =="
psql "$DB_URL" -v ON_ERROR_STOP=1 -c "
SELECT extname, extversion
FROM pg_extension
WHERE extname = 'timescaledb';
"

执行方式：

export DB_URL="postgresql://postgres:postgres@127.0.0.1:5432/app"
bash upgrade-timescaledb.sh

如果你使用 Docker，可以先用测试库验证扩展升级过程。下面是一个最小示例，便于在本地复现基本动作；镜像标签请按你的实际版本策略替换。

docker run --rm --name tsdb-test \
  -e POSTGRES_PASSWORD=postgres \
  -p 5432:5432 \
  -d timescale/timescaledb:latest-pg16

sleep 10

psql "postgresql://postgres:postgres@127.0.0.1:5432/postgres" -v ON_ERROR_STOP=1 <<'SQL'
CREATE EXTENSION IF NOT EXISTS timescaledb;
SELECT extname, extversion FROM pg_extension WHERE extname = 'timescaledb';
SQL

注意：这个 Docker 示例只演示 extension 的创建与版本检查，不等价于生产升级。生产环境仍应先备份、在预发恢复真实数据、跑核心查询和写入链路。

升级后重点看哪些信号

由于本次修复集中在迁移和索引相关问题，升级后建议至少检查这些项目：

-- 1. 确认扩展版本
SELECT extname, extversion
FROM pg_extension
WHERE extname = 'timescaledb';

-- 2. 查看 hypertable 基本状态
SELECT hypertable_schema, hypertable_name, num_chunks
FROM timescaledb_information.hypertables
ORDER BY hypertable_schema, hypertable_name;

-- 3. 查看后台任务状态
SELECT job_id, application_name, schedule_interval, scheduled, config
FROM timescaledb_information.jobs
ORDER BY job_id;

-- 4. 如果使用压缩、保留策略或连续聚合，检查任务错误日志
SELECT *
FROM timescaledb_information.job_errors
ORDER BY finish_time DESC
LIMIT 20;

如果你们使用了 first() / last() 聚合相关查询，且依赖稀疏索引优化，建议把这些查询纳入升级后的回归测试。可以用 EXPLAIN 对比升级前后的计划：

EXPLAIN (ANALYZE, BUFFERS)
SELECT device_id, last(temperature, time)
FROM metrics
WHERE time >= now() - interval '1 day'
GROUP BY device_id;

这里的 metrics、device_id、temperature、time 需要替换成你的真实表和列名。

生产采用建议

这类补丁版本的核心原则是：不要因为“只是小版本”就跳过验证，也不要因为“没有新功能”就无限期拖延。

建议采用以下节奏：

正在使用 2.28.1：优先安排升级到 2.28.2。
有大量 hypertable 或复杂迁移历史：先在预发环境恢复一份近期生产备份，执行完整 extension 升级。
依赖后台任务：升级后观察压缩、保留策略、连续聚合等 job 是否正常运行。
依赖 first/last 查询优化：保留升级前后的查询计划和延迟指标，避免只看功能是否返回结果。
存在自定义索引策略：关注 bloom filter、稀疏索引相关对象，尤其是历史版本遗留配置。

TimescaleDB 2.28.2 不像大版本那样需要重新设计架构，但它修复的是升级和元数据路径上的坑。对时序库来说，数据写入可以慢一点，升级过程不能赌运气。把备份、预发演练、版本确认和核心查询回归放进同一个 checklist，这次升级就会稳得多。