Postgres · XB 现场笔记

事务拿锁时别的请求会礼貌等待

Wed, 16 Feb 2028 00:00:00 +0000

等待锁可能是正常协调，也可能让连接和请求持续排队。PostgreSQL 的 lock_timeout 可以让调用方停止等待，但它不会解释持锁者为什么慢，更不会自动决定业务是否可以重试。应从操作能够接受的延迟出发设定预算，同时找到实际阻塞者；单纯延长超时或增加尝试次数，可能只是扩大同一条等待队列。

坏掉的样子

锁超时分别作用于每一次锁获取尝试，包括语句隐式申请的锁。它测量的是等待当前锁的时间，而不是整条语句的总运行时间。查询已经执行了一段时间，随后又申请一把锁，仍然可能触发这个限制。反过来，多次较短的等待也可能累计超过一个配置间隔。把锁超时理解成“只有语句刚开始时检查一次”，或把它当成整次查询的总截止时间，都会漏掉真实的等待范围。

statement_timeout 限制整条语句执行，其中也包括等锁。如果它更短，可能先于锁超时取消语句。空闲事务会话超时处理的则是另一种状态：事务还开着，但服务器正在等待客户端发下一条命令。卡在更新内部等待锁的后端通常仍是活动状态，等待事件属于锁；不能看到连接排队，就直接把所有等待者叫作空闲事务。真正闲着不提交的持锁者和正在等待的受阻者，需要分别定位。

PostgreSQL 十八还提供事务超时，事务持续过久时会终止整个会话。这与锁超时仅取消语句的失败边界不同，连接池必须丢弃已经断开的连接。两种设置都不是跨多次尝试的应用总截止时间；事务开始前的排队，以及重试退避期间的耗时，仍应计入调用方预算。不要把一个数据库内计时器当成完整请求的时间保证。

配置超时与 SQLSTATE 说明作用范围；先回滚再重试。配置毫秒数不是测得的客户端延迟。

快速验证

准备同一个 PostgreSQL 18 可丢弃数据库，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。使用同一角色并具备创建模式权限，确认 timeout_demo 尚不存在，显式事务外保持自动提交。实验使用默认的零值锁超时，且没有其他会提前干预的超时设置。下面的毫秒参数只用于快速复现，不是生产建议值。甲先建立独立模式和计数表：

CREATE SCHEMA timeout_demo;
CREATE TABLE timeout_demo.counter (id integer PRIMARY KEY,n integer);
INSERT INTO timeout_demo.counter VALUES (1,0);

甲在显式事务中把数字改成十，暂时不提交，也不回滚，以便继续持有目标行的锁：

BEGIN;
UPDATE timeout_demo.counter SET n=10 WHERE id=1;

乙开启事务，对同一行加一，并给取锁等待一百毫秒预算；这不是客户端观察耗时的严格上界。为展示预期错误及后续事务状态，只在这一小段临时关闭遇错停止：

BEGIN;
SET LOCAL lock_timeout='100ms';
SET LOCAL statement_timeout='1s';
\set ON_ERROR_STOP off
UPDATE timeout_demo.counter SET n=n+1 WHERE id=1;
\echo lock_state :SQLSTATE
SELECT n FROM timeout_demo.counter WHERE id=1;
\echo transaction_state :SQLSTATE
\set ON_ERROR_STOP on
ROLLBACK;

下列结果是原有双会话练习的预期结果，本轮未重新执行并发会话。先得到 55P03，随后查询得到 25P02。前者取消乙的更新，并使这个显式事务进入失败状态；后者说明原事务不能继续正常执行。乙的回滚只清理自己的失败事务，不会释放甲的锁，也不会取消甲尚未提交的十。若忽略回滚，直接在原事务里重发更新，只会继续收到事务状态错误。

甲仍保持事务打开。乙重新开始，这次把整条语句预算设成五十毫秒，比取锁的一百毫秒更短：

BEGIN;
SET LOCAL lock_timeout='100ms';
SET LOCAL statement_timeout='50ms';
\set ON_ERROR_STOP off
UPDATE timeout_demo.counter SET n=n+1 WHERE id=1;
\echo statement_state :SQLSTATE
\set ON_ERROR_STOP on
ROLLBACK;

此时得到 57014，说明语句取消先发生。等待的依然是同一行，改变的只是哪个计时器先到期。错误码需要结合上下文解释：不等待的取锁请求也可能返回 55P03，其他查询取消也可能返回 57014。单看这些类别，既不能认定已经检测到死锁，也不能直接知道阻塞者属于哪个应用操作。

甲现在回滚，丢弃尚未提交的十并释放行锁：

ROLLBACK;

乙开启一个新的有界事务，再次更新，这次返回一并成功提交：

BEGIN;
SET LOCAL lock_timeout='100ms';
SET LOCAL statement_timeout='1s';
UPDATE timeout_demo.counter SET n=n+1 WHERE id=1 RETURNING n;
COMMIT;

结果是一，因为乙先前的失败尝试都没有提交增量，甲的十也已回滚。乙继续验证普通执行时间与取锁等待时间的区别：

BEGIN;
SET LOCAL lock_timeout='50ms';
SET LOCAL statement_timeout='1s';
SELECT pg_sleep(0.2);
\echo sleep_state :SQLSTATE
COMMIT;
SHOW lock_timeout;

睡眠持续二百毫秒，超过锁等待预算五十毫秒，但正常返回成功状态。没有等待锁，不能仅凭耗时长就触发锁超时。提交之后，显示的锁超时恢复为会话原来的零，因为局部设置只持续到当前事务结束。所有打印的 SQLSTATE、恢复后的超时设置与最终计数都要人工比较，脚本没有自动断言这些结果。最后由甲核对数据仍为一，并清理实验；如果中断，应先回滚双方实验事务，再移除实验模式：

SELECT n FROM timeout_demo.counter WHERE id=1;
DROP SCHEMA timeout_demo CASCADE;

恢复时不要扩大竞争

是否重试应由具体操作决定。锁超时后先回滚，只有剩余请求预算足够、并且重放符合业务语义时，才开始新事务。少量尝试、随机退避和总截止时间可以限制额外负载，却不能让永久占用的资源凭空可用。耗尽预算时应保留最终错误和尝试次数，而不是静默丢弃请求，或把它报告成成功。

真正的死锁是依赖关系形成了环，数据库检测后会返回死锁错误。锁超时也可能抢在死锁检测之前到期，所以“这次只看见超时”不能证明没有循环等待。应结合阻塞进程、事务持续时间与取锁顺序检查原因。让持锁事务早点结束，特别是移走其中等待用户输入或外部服务的环节，往往比整体调大超时更有效。生产参数必须参考正常锁持有时间和业务延迟预算，不能照抄这个实验的毫秒数。

来源

PostgreSQL 18 客户端连接默认值，锁等待、语句与空闲事务超时的作用范围，已核验 2026-10-15。
PostgreSQL 18 显式锁，锁冲突及死锁检测，已核验 2026-10-15。
PostgreSQL 错误码，锁不可用、查询取消和失败事务的 SQLSTATE 分类，已核验 2026-10-15。

部分索引的写入成本

Tue, 15 Feb 2028 00:00:00 +0000

部分索引筛选的是行，不是裁剪列。给 id 建索引并加上 WHERE status = 'open'，保存的是未关闭行的标识符；状态列决定哪些行进入索引，却不因此成为搜索键。估算维护成本时，这个区别很重要：即使某一列的值没有存进索引键，它仍可能影响更新需要付出的代价。

如果订单表大部分是已关闭的历史记录，把这些行排除在索引之外，确实可能省下大量索引空间。但这不代表历史行可以免费写入，也不保证查询一定更快，更不会消除数据表本身的清理工作。判断收益时，要同时看结构缩小了多少，以及维持正确状态仍需承担哪些写入。

成员资格决定哪些行入索引；写入成本还取决于键变化、谓词列依赖和同页 HOT 条件。

区分成员资格与更新成本

新插入的行不满足谓词时，这一个部分索引不需要为它新增条目。谓词判断、表内存储、其他索引以及正常事务处理仍然存在。把一行从子集外改到子集内，需要新增条目；把它改出子集，则会改变当前查询能看见的成员。旧行版本与过时索引条目的物理回收可能发生在之后，不能把逻辑上退出子集理解成立即释放所有存储空间。

成员资格没有变化，也不等于可以跳过索引维护。未关闭订单的标识符改变了，索引键就需要更新。即使只修改一列与索引无关的备注，只要数据库无法采用堆内元组更新，也就是 HOT，新行版本仍可能需要新的索引条目。因此，“谓词结果不变”不足以证明这次更新很便宜。

对本文讨论的 PostgreSQL 18 B-tree 索引，HOT 要求所有索引定义引用的列值保持不变，包括表达式引用的列和部分索引谓词引用的列；原来那张堆页面还必须容得下新行版本。把状态从已关闭改成已归档，两种状态虽然都不满足谓词，仍然改变了索引依赖的状态列，会阻止 HOT。只修改没有被任何索引引用的备注列，则可能满足条件。

降低表的填充比例可以为页面内更新预留空间，但不是保证成功的开关。检查时必须看整张表的索引集合，另一个索引可能恰好引用备注列，独立阻止这次优化。只盯着准备新增的那个部分索引，会漏掉其他定义施加的限制。

规则还依赖版本和索引方法。PostgreSQL 16 开始允许只改变 BRIN 等汇总索引引用列的更新使用 HOT，汇总信息仍可能需要维护。这项例外不适用于这里的 B-tree 索引。把一个版本、某种索引上的测试结论搬到其他部署之前，应先核对对应版本的文档。

可以使用与值得使用是两回事

规划器必须能够证明，查询条件蕴含部分索引的谓词。只包含未关闭订单的索引，不能单独回答还可能需要已关闭订单的请求。通用计划里的 status = $1 无法提供这个证明；按具体参数生成的定制计划则可能知道传入值。若状态条件本来就是固定的 status = 'open'，仅把其他查询值参数化，并不会抹掉这个事实。

有资格参与选择的索引，仍要与其他访问路径比较成本。表很小或者结果覆盖面很广时，顺序扫描可能更合适。看到计划没有采用部分索引，先检查估算行数、实际行数与缓冲区访问，再判断是不是谓词写法导致无法匹配。机械要求计划永远出现某个索引名，会把性能假设误当成正确性要求；结果是否完整正确与路径是否足够便宜，应该分别验证。

坏掉的样子

积压越来越多，原本很小的未关闭子集也可能占据大部分数据；频繁的状态切换，还可能抵消预期的写入节省。应使用有代表性的查询和状态转换比较，而不是只凭两个索引的体积推导吞吐量。大量重叠的部分索引会增加规划与维护工作，不能把每个报表的过滤条件都独立变成一个索引。

新增切片或删除看起来没人扫描的索引之前，要检查完整索引集合与业务规则。尤其是承担唯一性约束的索引，即使查询扫描次数很低，也可能一直在保护数据完整性。体积变大或扫描次数减少，意味着需要重新评估，不是可以直接删除的充分证据。

快速验证

在可丢弃的 PostgreSQL 18 数据库中，打开一个新的 psql -X -v ON_ERROR_STOP=1 会话，并确认已启用 track_counts，依次运行两个代码块。历史审阅记录报告，下面的 SQL 曾在 PostgreSQL 18.6 的无套接字单用户模式中执行，本次没有重跑；尚未验证客户端连接服务器的路径。临时表共有两万行，其中两百行未关闭。显式命名索引，避免依赖数据库自动生成的名字。

BEGIN;
CREATE TEMP TABLE partial_cost_demo (
 id integer NOT NULL,
 status text NOT NULL,
 note integer NOT NULL
) WITH (fillfactor=50);
INSERT INTO partial_cost_demo
SELECT g, CASE WHEN g % 100 = 0 THEN 'open' ELSE 'closed' END, 0
FROM generate_series(1,20000) AS g;
CREATE INDEX cost_all_id ON partial_cost_demo (id);
CREATE INDEX cost_open_id ON partial_cost_demo (id) WHERE status='open';
ANALYZE partial_cost_demo;
SELECT pg_relation_size('cost_all_id') AS full_bytes,
 pg_relation_size('cost_open_id') AS partial_bytes;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id FROM partial_cost_demo WHERE status='open' ORDER BY id LIMIT 5;
SELECT id FROM partial_cost_demo WHERE status='open' ORDER BY id LIMIT 5;

查询结果应为一百、两百、三百、四百和五百。部分索引预计占用更少字节，但不要要求体积精确等于全量索引的百分之一，页面本身也有开销。记录实际选中的计划，不要断言某一种固定形状。全量索引与部分索引使用同样的键，提供体积对照，同时也会参与访问路径竞争。

UPDATE partial_cost_demo SET note=1 WHERE id=100;
SELECT n_tup_upd, n_tup_hot_upd FROM pg_stat_xact_user_tables
WHERE relid='partial_cost_demo'::regclass;
UPDATE partial_cost_demo SET status='archived' WHERE id=101;
SELECT n_tup_upd, n_tup_hot_upd FROM pg_stat_xact_user_tables
WHERE relid='partial_cost_demo'::regclass;
SELECT count(*) FROM partial_cost_demo WHERE status='open';
ROLLBACK;

这里使用当前事务的统计视图，计数会随本事务中的操作持续更新，不必等待累计统计刷新。更新总数应从一次增加到两次。备注更新可能增加 HOT 次数；状态改变不应增加 HOT 次数，即使它前后都不属于未关闭子集。隔离测试中，两次记录的更新总数与 HOT 次数分别为（一，一）和（二，一），未关闭行仍有两百行。全量和部分索引的大小分别为四十六万六千九百四十四与一万六千三百八十四字节，选中的仅索引扫描仍访问了五次堆。这里记录的是特定实验的观察值，不是所有环境都应相同的结果。回滚后实验对象和数据已被移除。

这个练习把索引子集大小与 HOT 条件分开观察，并没有测量长期运行的生产负载。临时表上的耗时不能证明生产 WAL 节省，也不能证明持续写入吞吐量。真正的上线判断还需要同等负载、同等索引集合，以及有代表性的页面空间和更新分布。

来源

PostgreSQL 18 部分索引，成员资格、逻辑蕴含与过量部分索引，已核验 2026-10-15。
PostgreSQL 18 HOT，更新条件与页面空间，已核验 2026-10-15。
PostgreSQL 18 HOT 实现说明，谓词列依赖和元组链，已核验 2026-10-15。
PostgreSQL 16 发行说明，第十六版引入的 BRIN 例外，已核验 2026-10-15。
PostgreSQL 18 PREPARE，定制计划与通用计划，已核验 2026-10-15。
PostgreSQL 18 统计系统，当前事务的统计计数，已核验 2026-10-15。
PostgreSQL 18 EXPLAIN，实际执行与缓冲区测量，已核验 2026-10-15。
PostgreSQL 18 体积函数，关系主数据分支的大小，已核验 2026-10-15。

分区裁剪跳过查询不可能用到的整张分区

Sun, 13 Feb 2028 00:00:00 +0000

分区裁剪排除的是整张不可能包含匹配行的分区。它与在剩余分区内部利用索引寻找行不同，也不是按页工作的缓存技巧。PostgreSQL 可以在查询规划阶段完成排除，也可以等参数值在执行过程中可用后再裁剪。要判断它是否生效，需要查看实际访问的分区，而不是只看最终返回了多少行。

证明哪些分区不可能命中

声明式分区的边界来自分区键。把日期键限制在十月，可以证明九月和十一月与查询无关。裁剪依赖这些边界，而不是估计其他分区“可能很少匹配”。统计信息仍影响其他规划决策，但行数估计不准，不会让分区归属变成概率判断；这两个层面的信息应分开解释。

裁剪不要求先建索引。排除无关分区后，如果剩余分区的大部分行都需要读取，PostgreSQL 完全可能选择顺序扫描。所以，出现 Index Scan 并不是裁剪成功的判据。应先检查物理关系名和计划结构，再单独评价剩余每张表内部的访问方式。顺序扫描一张相关分区，仍然可能已经省掉其他分区的大量工作。

条件必须能对应分区键及其比较语义。把日期列转换成文本，可能隐藏直接的边界关系，即使某个字符串条件恰好仍选出相同行。应使用有类型的参数和直接表达目标区间的条件，不能假定分区键外面套任意表达式都保留裁剪能力，甚至不能默认它保留原来的日期语义。

参数也能在执行时触发裁剪

常量可以支持规划期裁剪，使计划只留下相关子表。预备语句的通用计划无法提前知道未来每次传入的参数值，但这不表示它必须扫描全部分区：执行初始化时已经知道的值，也可以用于执行期裁剪。看见通用计划中原本存在多个分支，还不足以判断最终都会读取。

EXPLAIN ANALYZE 用 Subplans Removed 报告初始化阶段排除的分区。另一些情况，例如嵌套循环内侧参数在执行期间变化，可以在实际执行过程中继续裁剪。分析这些场景时，需要查看循环次数和子计划是否运行。某个节点显示从未执行，也可能是外层没有输入等其他原因，不能脱离完整计划单独当成裁剪证据。

因此，不能把这些规则简化成“只要不是常量表达式，就会失去裁剪”。参数何时可用，以及表达式是否受支持，共同决定何时能够排除分区。定制计划和通用计划可能不同，但返回同样答案。尤其要注意，同一个通用计划参数可以支持运行时分区裁剪，却不满足部分索引在规划期要求的谓词证明。这两种优化使用的信息时点不同，不能把一个实验的限制直接套到另一个机制上。真正值得确认的是：负载使用真实参数时，哪些分区实际被访问了。

坏掉的样子

只过滤无关字段，可能让所有分区仍然相关；把键转换成无法对应边界的表达式，也可能产生同样结果。调整分区布局前，应检查准确条件和 enable_partition_pruning 设置。手工添加相互矛盾的 CHECK 约束并不是修复方法；普通本地声明式分区会执行自己的边界规则，而基于 CHECK 的约束排除是另一种优化机制。

裁剪也不保证没有锁或规划成本可以忽略。执行初始化阶段排除的分区，在执行开始时仍然会被锁定。大型分区层级可能消耗规划时间和会话内的元数据内存，即使最后只扫描少数子表。应根据真实查询和维护模式选择层级，而不是追求尽可能多的分区数量。

最后，即使裁掉两个分区，第三个分区内部仍可能有几千条无关行。合适的局部索引可能帮助第二阶段。最终返回一百行，不证明只检查了一百行；缓冲命中也不等于物理磁盘读取。必须沿着计划节点看清扫描、过滤与输出之间的区别。

分区边界证明、初始化裁剪与分区内工作分开。历史计划观察仅限该夹具；排除不证明没有锁。

快速验证

把下面内容保存为 partition-pruning.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f partition-pruning.sql。脚本在事务内启用裁剪，并用通用预备计划展示初始化阶段的行为。临时分区上没有建立任何索引。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL datestyle='ISO, YMD';
SET LOCAL enable_partition_pruning=on;
CREATE TEMP TABLE observations (day date,id integer) PARTITION BY RANGE(day);
CREATE TEMP TABLE obs_sep PARTITION OF observations FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
CREATE TEMP TABLE obs_oct PARTITION OF observations FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');
CREATE TEMP TABLE obs_nov PARTITION OF observations FOR VALUES FROM ('2026-11-01') TO ('2026-12-01');
INSERT INTO observations SELECT DATE '2026-09-01'+g%90,g FROM generate_series(0,8999) AS g;
ANALYZE observations;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT count(*) FROM observations WHERE day>=DATE '2026-10-01' AND day<DATE '2026-11-01';
SET LOCAL plan_cache_mode=force_generic_plan;
PREPARE by_day(date) AS SELECT count(*) FROM observations WHERE day=$1;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) EXECUTE by_day(DATE '2026-10-10');
EXECUTE by_day(DATE '2026-10-10');
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT count(*) FROM observations WHERE day::text='2026-10-10';
DO $$ BEGIN
 IF (SELECT count(*) FROM observations WHERE day=DATE '2026-10-10') <> 100 OR
 (SELECT count(*) FROM observations WHERE day>=DATE '2026-10-01' AND day<DATE '2026-11-01') <> 3100 THEN
 RAISE EXCEPTION 'unexpected pruned result';
 END IF;
END $$;
DEALLOCATE by_day;
ROLLBACK;

保留的 PostgreSQL 18.6 单用户 SQL 适配日志显示，只扫描 obs_oct，读取十月的三千一百条匹配行。本轮源文审阅没有重跑。未测试 psql 传输或并发分区锁。通用日期查询报告 Subplans Removed 为二，返回一百行，但仍需在十月分区中过滤三千条其他记录。这同时展示了成功排除无关分区，以及相关分区内部尚未消除的工作量。

文本转换条件扫描三个子表，在明确指定 ISO DateStyle 后，仍返回相同的一百行。断言检查有类型查询的结果数量，DEALLOCATE 和回滚分别清理预备语句与临时表。这个结果验证当前示例中条件与裁剪的关系；选择索引或调整生产分区粒度前，还应测量有代表性的实际计划，不能直接把小实验的结构当成性能收益保证。

来源

PostgreSQL 表分区，规划期与执行期裁剪、边界及锁行为，已核验 2026-10-15。
PostgreSQL PREPARE，通用与定制计划及参数处理，已核验 2026-10-15。
PostgreSQL 部分索引，规划期谓词蕴含要求，已核验 2026-10-15。

表分区按范围或键拆分数据

Thu, 10 Feb 2028 00:00:00 +0000

范围分区把边界定义变成写入路由规则。PostgreSQL 按键值把行放到能够接受它的分区，无论这条数据准时到达，还是晚了几个月。任何查询获得裁剪收益之前，都需要先定义正确边界、使用匹配的时间类型，并安排缺失范围的处理流程。分区建表成功，只是这些条件中的一部分。

使用相邻的左闭右开范围

范围分区包含下界，不包含上界。九月可以从九月一日开始，一直到十月一日之前；十月正好从同一边界开始，双方不会重叠。不要靠猜测一个月最后可表示的时间戳来定义范围。相邻的左闭右开区间，不依赖时间字段究竟保留多少位小数，也能避免边界遗漏。

查询同样需要准确表达区间。大于等于下界、小于上界的条件，适合描述一个月的数据。BETWEEN 包含两个端点，因此，把下月第一瞬间写成其上界，可能把下个月的数据也查进来。分区路由只能执行数据布局规则，不能替一个请求了错误区间的条件修正业务含义。

分区键类型与时区也是定义的一部分。timestamptz 代表瞬间，不带时区的 timestamp 则代表没有对应时区解释的本地日期时间。示例为每个边界显式写出 UTC 偏移。如果业务月份按另一个时区划分，应根据那个时区的规则推导边界，而不是假定所有本地日期都对应相同的实际时长。

缺失范围是一种运维状态

没有分区接受新键值时，插入会报错，除非 DEFAULT 分区能够接住它。日历进入新月份，并不会让 PostgreSQL 自动创建下一张月表。应在写入需要之前创建范围，同时考虑迟到数据和旧日期修正。输入键不必单调增长，路由照样能够工作；关键是相应目标范围仍然存在。

DEFAULT 可以接收显式范围之外的值，减少立即发生的插入失败，但如果不检查默认表，也会掩盖分区管理遗漏。持续增长的默认分区可能混入多个互不相关的时间范围，让后续整理更困难。应让“有意保留的例外数据”与“忘记创建分区的日常数据”保持可辨认，不能把插入暂时不报错当成管理正常。

新增显式分区，会改变默认分区能够接受的值。如果新范围对应的行还留在 DEFAULT 中，PostgreSQL 会拒绝变更，而不会允许两处同时拥有这批数据。应先把这些行迁移到合适的暂存表或按规则处理，再挂载新分区。边界是被执行的数据规则，不是可以随意标错的说明标签。

坏掉的样子

下一月分区未创建时，部署可能恰好在跨月瞬间出现写入失败。补建分区又可能因为 DEFAULT 已经积累对应行而失败。这两种问题都属于路由和数据位置，不是规划器统计陈旧。应先检查被拒绝的键和当前边界，再决定操作，不能直接运行 ANALYZE 或改索引，希望它们修复缺失范围。

ATTACH 可能扫描候选表以验证边界，也可能检查默认分区中是否存在冲突数据。合适且已验证的约束能省去部分扫描，但操作仍需要锁，并要求表结构兼容。PostgreSQL 十八的 ATTACH 在父表上取得 SHARE UPDATE EXCLUSIVE，在候选表和存在的 DEFAULT 表上取得 ACCESS EXCLUSIVE。省掉验证扫描，并不等于省掉这些取锁要求。活跃表上迁移数据时，需要协调写入者和锁获取；一个隔离环境中的事务示例，不是完整的在线迁移操作方案。

是否允许空值，与范围选择是两回事。示例要求时间戳非空，避免缺失事件时间悄悄变成普通的例外数据。迁移后还应核对行数和标识；ATTACH 成功不能证明更早的复制步骤没有丢行或重复，数据核对不能省略。

范围边界与 DEFAULT 成员关系是强制数据规则。迁移与挂载限于隔离夹具，锁和竞争写入者需要另外验证。

快速验证

把下面内容保存为 partition-ranges.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f partition-ranges.sql。全部表都是临时表，整个实验最后回滚清除。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL timezone='UTC';
CREATE TEMP TABLE samples (at timestamptz NOT NULL,id integer) PARTITION BY RANGE(at);
CREATE TEMP TABLE samples_sep PARTITION OF samples
FOR VALUES FROM ('2026-09-01 00:00:00+00') TO ('2026-10-01 00:00:00+00');
INSERT INTO samples VALUES ('2026-09-01 00:00:00+00',1),('2026-09-30 23:59:59.999999+00',2);
DO $$ BEGIN
 INSERT INTO samples VALUES ('2026-10-01 00:00:00+00',3);
 RAISE EXCEPTION 'upper boundary entered September';
EXCEPTION WHEN check_violation THEN RAISE NOTICE 'upper boundary needs another partition';
END $$;
CREATE TEMP TABLE samples_default PARTITION OF samples DEFAULT;
INSERT INTO samples VALUES ('2026-10-01 00:00:00+00',3);
DO $$ BEGIN
 CREATE TEMP TABLE samples_oct_bad PARTITION OF samples
 FOR VALUES FROM ('2026-10-01 00:00:00+00') TO ('2026-11-01 00:00:00+00');
 RAISE EXCEPTION 'new partition overlapped populated default';
EXCEPTION WHEN check_violation THEN RAISE NOTICE 'matching default rows must be moved first';
END $$;
CREATE TEMP TABLE samples_oct (LIKE samples INCLUDING ALL);
WITH moved AS (
 DELETE FROM samples_default
 WHERE at >= TIMESTAMPTZ '2026-10-01 00:00:00+00' AND at < TIMESTAMPTZ '2026-11-01 00:00:00+00'
 RETURNING *
) INSERT INTO samples_oct SELECT * FROM moved;
ALTER TABLE samples ATTACH PARTITION samples_oct
FOR VALUES FROM ('2026-10-01 00:00:00+00') TO ('2026-11-01 00:00:00+00');
SELECT id,at,tableoid::regclass AS physical_table FROM samples ORDER BY id;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY id) FROM samples_sep) IS DISTINCT FROM ARRAY[1,2] OR
 (SELECT array_agg(id ORDER BY id) FROM samples_oct) IS DISTINCT FROM ARRAY[3] OR
 (SELECT count(*) FROM samples_default) <> 0 THEN
 RAISE EXCEPTION 'range migration lost or duplicated data';
 END IF;
END $$;
ROLLBACK;

保留的 PostgreSQL 18.6 单用户 SQL 适配日志显示，接受九月的第一瞬间，以及测试中十月开始前的最后一个微秒；本轮源文审阅没有重跑。未测试客户端传输和并发迁移。没有相应目标时，十月一日被拒绝；创建 DEFAULT 后，这一行进入默认分区。随后尝试新增十月分区，因为匹配行仍留在 DEFAULT 中而失败，说明系统确实检查数据归属，并没有仅仅更新元信息。

脚本用 DELETE RETURNING 把该行移到暂存表，再把暂存表挂载为十月分区，并通过 tableoid 展示每条记录的实际物理表。标识一和二仍在九月，标识三位于十月，DEFAULT 为空。断言检查最终成员关系和行数，同时覆盖边界包含规则与完整迁移路径。这个结果不能被解释为未来范围管理可以省略，只说明测试中的布局已经正确完成。

来源

PostgreSQL 表分区，范围边界和路由行为，已核验 2026-10-15。
PostgreSQL ALTER TABLE，挂载验证、默认分区与锁，已核验 2026-10-15。

窗口函数在不合并组的前提下排名

Tue, 08 Feb 2028 00:00:00 +0000

排名函数为分区内的每一条输入行附加位置，不会把整个团队、部门或客户的数据压缩成一行聚合结果。真正需要选择的是并列的含义：每行占一个独立位置、允许并列且保留空位的竞赛名次，还是按不同分数组连续计数的名次。三种规则解决的问题不同，应先确定业务规则再写窗口。

三个问题对应三种排名

row_number() 从一开始给每行分配连续整数。如果两行的排序值完全相同，而窗口没有其他区分条件，它们的相对序号没有保证。需要恰好选出两位获胜者时，可以按分数降序，再按稳定且唯一的标识排序。这意味着同分时由标识决定谁占据剩余名额，不能把这个结果当成不影响业务的技术细节。

rank() 给同组并列行分配该组第一行的位置。分数为一百、九十、九十、八十时，名次依次为一、二、二、四。两位第二名占用了两个位置，因此下一档分数前面会留下空位。dense_rank() 则计算同分组的数量，对同一批数据给出一、二、二、三，不会因并列人数增加而跳号。

并列组由窗口 ORDER BY 中的全部表达式决定。如果把唯一标识也加入 rank 的窗口，即使本意只是稳定展示顺序，也会让原来的同分行不再并列。row_number 需要标识裁决、rank 需要保留同分时，应使用不同窗口定义。最终结果的展示顺序可以由外层 ORDER BY 控制，不必因此改掉排名所依据的并列关系。

明确分区与过滤时机

PARTITION BY 让每个组从头编号。不写分区条件时，窗口看到的所有输入行属于同一个分区。这和窗口帧是不同概念：排名依据分区顺序和并列组，不是对某段移动聚合帧计数。添加 ROWS 边界，不会把 rank 变成“这个边界内有多少行”的函数。

窗口看到的是 FROM、WHERE、分组和 HAVING 处理后剩余的行。因此，在同层查询中过滤，可能先删掉部分竞争者，再计算名次。如果需要先给所有人排名，再挑前几个位置，应在子查询或 CTE 中生成窗口值，然后到外层过滤。PostgreSQL 不允许直接把窗口函数放进 WHERE，这也提醒读者区分排名输入与排名输出。

“前两名”必须有明确含义。位置不大于二，每个分区最多返回两行；竞赛名次不大于二，会保留全部并列第二名，结果可能超过两行；密集名次不大于二，则选择前两个不同分数组。当第一档分数本身就有多人并列时，密集排名与竞赛排名的筛选结果也可能不同。这些是不同的结果集合，不是可以随意互换的性能写法。

排名保留的是当前查询提供的行，不保证原始实体恰好一行。一对多连接可能在编号之前复制参赛者，导致同一实体占据多个位置。应先说明输入粒度并解决非预期的连接膨胀，再筛选前若干名。事后添加 DISTINCT 即使删掉重复输出，也不一定修复已经计算的名次；连接产生的行数本身就是排名语义的一部分。

坏掉的样子

row_number 缺少确定的并列裁决条件时，同分选手可能在重复查询中交换位置。反过来，在所有窗口都添加标识，又可能悄悄消除 rank 本来要保留的并列。测试时必须放入恰好卡在截止名次上的同分数据，不能只测每个分数都不同的情况。如果分数允许 NULL，还应明确空值顺序；PostgreSQL 降序默认把空值放前面，需要时应显式指定 NULLS LAST。

确定的排序也不能冻结持续变化的数据。新分数出现后，已有行可能在两次请求之间移动，所以偏移分页或保存的行号并不是持久身份。大规模排名可能需要排序和临时文件，多个不同的窗口顺序也可能增加处理步骤。应读取有代表性的执行计划，不能因为查询使用窗口函数，就假设一定只有一次廉价扫描。

并列改变名次。依据文章示例与明确限制静态绘制；未为本图执行 SQL。

快速验证

把下面内容保存为 ranking.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f ranking.sql。red 分区包含一次并列，blue 是独立分区；末尾回滚会清理临时表和临时视图。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE scores (id integer, team text, score integer);
INSERT INTO scores VALUES (1,'red',100),(2,'red',90),(3,'red',90),(4,'red',80),(5,'blue',50);
CREATE TEMP VIEW ranked AS
SELECT *, row_number() OVER (PARTITION BY team ORDER BY score DESC,id) AS position,
 rank() OVER w AS rank_with_gaps, dense_rank() OVER w AS rank_without_gaps
FROM scores WINDOW w AS (PARTITION BY team ORDER BY score DESC);
SELECT * FROM ranked ORDER BY team,id;
SELECT count(*) AS top_two_positions FROM ranked WHERE team='red' AND position<=2;
SELECT count(*) AS top_two_ranks FROM ranked WHERE team='red' AND rank_with_gaps<=2;
DO $$ BEGIN
 IF (SELECT array_agg(rank_with_gaps ORDER BY id) FROM ranked WHERE team='red')
 IS DISTINCT FROM ARRAY[1,2,2,4]::bigint[] THEN RAISE EXCEPTION 'wrong rank'; END IF;
 IF (SELECT array_agg(rank_without_gaps ORDER BY id) FROM ranked WHERE team='red')
 IS DISTINCT FROM ARRAY[1,2,2,3]::bigint[] THEN RAISE EXCEPTION 'wrong dense rank'; END IF;
 IF (SELECT array_agg(id ORDER BY position) FROM ranked WHERE team='red' AND position<=2)
 IS DISTINCT FROM ARRAY[1,2] THEN RAISE EXCEPTION 'unstable top two'; END IF;
 IF (SELECT count(*) FROM ranked WHERE team='red' AND rank_with_gaps<=2) <> 3 THEN
 RAISE EXCEPTION 'tied second place was dropped';
 END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 实测中，red 的位置为一至四，竞赛名次为一、二、二、四，密集名次为一、二、二、三。blue 独立从一开始。按 red 的位置筛选前两行，会得到标识一和二；按竞赛名次不大于二筛选，则返回三行，保留两位第二名。这同时说明“每行还在”与“每个分区重新计数”的行为。

断言检查两个名次数组、预定的同分裁决结果和截止处的行数。把共享排名窗口改为包含 id，应该让这些预期失败，从而暴露展示稳定性与并列语义被混用的问题。这里的观察来自固定数据集；若报表需要在分数持续变化时仍保持稳定，还必须单独设计快照或分页规则，不能让临时排名承担它没有承诺的身份语义。

来源

PostgreSQL 窗口函数，排名函数与并列组，已核验 2026-10-15。
PostgreSQL 窗口教程，分区、排序和排名后的过滤，已核验 2026-10-15。

自动清理资格不等于执行完成

Fri, 04 Feb 2028 00:00:00 +0000

繁忙表持续产生旧行版本，维护速度需要与这种产生速度匹配。降低自动回收门槛，可以让表更早具备被处理的资格，但“符合条件”并不等于“已经完成”。工作者仍需轮到这张表、获得所需锁，并在积压继续增长之前完成足够的有效清理。调优应观察这个完整循环，不能把一个参数值当成后台吞吐的保证。

坏掉的样子

普通更新和删除的触发条件，由固定门槛加上表行数估计乘比例因子构成；PostgreSQL 18 在启用上限时，还会应用最大触发门槛。插入触发清理、由事务年龄驱动的冻结，又有各自的运行原因。因此，只看一个死元组比例，会漏掉其他维护需求；每看见一次清理就断言更新删除门槛被触发，也可能误判真正原因。

把门槛调低，不能释放仍被旧快照需要的版本，也不能创造额外的磁盘吞吐。增加工作者或降低成本延迟，还可能加剧与前台查询的资源竞争。让死元组估计在每个瞬间都接近零，既不是通用的现实目标，也不能充分说明业务性能良好。真正需要维持的是可持续的清理能力、可接受的文件增长、请求延迟和维护成本。

2050 到 150 的计算要求有效上限禁用或至少为 2050。资格、自动执行与有效完成仍分开；运行待验证。

快速验证

本轮没有重跑原样保留的后台工作者集成。先前的自动清理观察属于历史记录，手动或单用户清理不能代替它。

使用 PostgreSQL 18 可丢弃实例，确认自动回收与统计收集已启用、有可用工作者，并使用正常的一分钟数据库检查间隔。通过一个全新的 psql -X -v ON_ERROR_STOP=1 连接执行下面的脚本。它最多等待一百三十秒，核对真实自动执行；如果超时，应把这次观察记为失败，不能手动清理一次就冒充自动任务已经运行。

CREATE SCHEMA churn_demo;
CREATE TABLE churn_demo.jobs (id integer PRIMARY KEY,n integer)
 WITH (autovacuum_enabled=false,
 autovacuum_vacuum_threshold=50,
 autovacuum_vacuum_scale_factor=0.2);
INSERT INTO churn_demo.jobs SELECT g,0 FROM generate_series(1,10000) AS g;
SELECT pg_stat_force_next_flush();
VACUUM (ANALYZE) churn_demo.jobs;
UPDATE churn_demo.jobs SET n=1 WHERE id<=1000;
SELECT pg_stat_force_next_flush();
SELECT n_live_tup,n_dead_tup,vacuum_count,autovacuum_count
FROM pg_stat_user_tables WHERE relid='churn_demo.jobs'::regclass;
SELECT 50+0.2*reltuples AS old_threshold,50+0.01*reltuples AS new_threshold
FROM pg_class WHERE oid='churn_demo.jobs'::regclass;
ALTER TABLE churn_demo.jobs SET
 (autovacuum_enabled=true,autovacuum_vacuum_scale_factor=0.01);
DO $$
DECLARE deadline timestamptz := clock_timestamp()+interval '130 seconds';
BEGIN
 LOOP
 PERFORM pg_stat_clear_snapshot();
 EXIT WHEN (SELECT autovacuum_count>0 FROM pg_stat_user_tables
 WHERE relid='churn_demo.jobs'::regclass);
 IF clock_timestamp()>deadline THEN
 RAISE EXCEPTION 'no automatic vacuum observed within the experiment budget';
 END IF;
 PERFORM pg_sleep(0.25);
 END LOOP;
END $$;
SELECT pg_stat_clear_snapshot();
SELECT n_dead_tup,last_autovacuum IS NOT NULL AS ran,autovacuum_count>0 AS counted
FROM pg_stat_user_tables WHERE relid='churn_demo.jobs'::regclass;
SELECT count(*),count(*) FILTER (WHERE n=1) FROM churn_demo.jobs;
DO $$ BEGIN
 IF (SELECT count(*) FROM churn_demo.jobs)<>10000
 OR (SELECT count(*) FROM churn_demo.jobs WHERE n=1)<>1000 THEN
 RAISE EXCEPTION 'maintenance changed application data';
 END IF;
END $$;
DROP SCHEMA churn_demo CASCADE;

测试表最初只关闭自己的常规自动回收，让初始化与受控更新先完成。手动清理并分析建立统计，同时清掉初始化插入积压，然后再更新一千行。显式统计刷新调用用于同步这个短实验，避免待发布的写入增量落在手动维护更新估计值之后；它不是建议在线业务频繁调用的调优开关。

启用工作者之前，预期存活和死亡元组估计分别为一万和一千，手动清理计数为一，自动清理计数为零。应用数据的准确行数会另外查询核对，不能用估计值取代。固定门槛设为五十时，原比例得到两千零五十，新比例得到一百五十。这个比较要求有效最大门槛被禁用，或至少为两千零五十；若配置了更小的上限，计算就会改变，不能只凭表小就认定上限没有作用。

一千个旧版本已经超过新的门槛。脚本随后开启这张表的常规自动回收，并只降低它自己的比例因子，再等待自动计数增加。轮询块每次丢弃统计缓存，避免在同一个观察事务中反复读取旧快照。开启工作者之后，脚本没有再次执行手动清理，所以最终的自动计数必须来自真实后台工作，而不是被实验自己的命令伪造出来。

最后预期死亡元组估计为零，自动清理时间非空，自动计数为正。业务数据仍有一万行，且恰好一千行的值已更新为一。本次测试实例在预算内观察到了后台任务完成，但具体等待时间取决于调度相位和工作者可用情况。因此，断言检查的是事件是否发生与数据是否保持正确，而不是固定等待多少秒就一定成功。

找到真正限制清理的阶段

如果一直没有自动执行记录，应检查表级有效选项、服务器自动回收设置、统计收集、工作者活动和冲突锁。手动维护时间不能代替自动维护时间。如果工作者确实完成了任务，但旧版本仍然保留，应检查长事务和其他可见性边界。如果版本已经允许移除，却产生得比处理更快，才需要进一步评估资源容量、成本节流和写入方式。

针对某张大而繁忙的表调整比例，通常比全局改变所有表更有针对性。修改前保留原选项，在具有代表性的多个负载时段里比较维护计数、文件增长与业务延迟，不能只用一次短暂空闲期得出结论。业务状态、表规模和写入模式改变以后，也应重新评估或恢复覆盖设置。

VACUUM 须在事务块之外运行。实验只在成功路径删除整套测试对象，错误可能留下模式及表级选项，仍需检查残留；真实表的配置则需要明确维护。即使更新流量后来降低，事务年龄与冻结需求仍然存在，不能因为死元组图表安静了就长期关闭后台工作。触发资格、执行记录、清理效果和前台代价同时得到验证，才足以判断这次调校是否有效。

来源

PostgreSQL 18 自动回收配置，门槛、比例、工作者限制与检查间隔，已核验 2026-10-15。
PostgreSQL 18 常规清理，触发公式及不同维护目的，已核验 2026-10-15。
PostgreSQL 18 累计统计，手动和自动计数及统计缓存，已核验 2026-10-15。
PostgreSQL 18 统计函数实现，实验用于同步观察的刷新辅助函数，已核验 2026-10-15。

代理键把身份与含义分开

Wed, 02 Feb 2028 00:00:00 +0000

代理主键把一行记录的身份与可能变化的业务值分开。客户修改邮箱时，订单仍引用同一个客户编号，而不必跟着邮箱一起改引用。这对于易变或较宽的业务键很有用，但稳定性来自数据库约束与应用规则，不是“自动生成”四个字本身。一个生成的数字不会天然不可修改、保密、全局唯一，也不能代替访问授权。

稳定标识来自规则与约束。生成机制、合法存储值、业务规则、引用和访问决定需要分别保证。

生成身份与约束唯一性

PostgreSQL identity 列从关联序列取得默认值。GENERATED ALWAYS AS IDENTITY 会拒绝普通显式赋值，GENERATED BY DEFAULT 则允许调用方提供值。即使使用 ALWAYS，导入时仍可通过 OVERRIDING SYSTEM VALUE 显式覆盖。两种形式都不会单独保证值唯一；需要拒绝重复标识时，仍须声明 PRIMARY KEY 或 UNIQUE 约束。

主键同时保证唯一与非空，并提供可供引用使用的索引。Identity 负责怎样生成默认值，约束负责哪些最终值允许存储，这两项职责不能混淆。导入时尤其如此：显式写入一个很大的编号，不会自动把序列推进到那个位置。若没有协调序列状态，后续生成值可能最终与导入行相撞，直到主键报错才暴露问题。

单独保留业务唯一规则

代理编号不会阻止相同业务实体重复出现。如果邮箱是唯一登录标识，应继续保留明确的唯一约束，并先决定规范化规则。普通 text 的 UNIQUE 使用该列的比较语义，不会暗中替应用处理大小写折叠、空白或各种邮箱等价规则。迁移之前就要明确这些行为，否则数据库认为不同的值，应用可能认为是同一账号，或者反过来。

子表如果不能出现悬空引用，就需要真实的外键约束。邮箱不是引用键时，修改它不会改变订单指向的客户，因为订单保存的是 id。这缩小了这一项修改的范围，却不能承诺所有业务改名都变成简单操作：搜索索引、审计记录、外部集成和缓存仍可能依赖邮箱，需要按实际调用链更新。数据模型只解决它真正覆盖的关系。

坏掉的样子

把序列编号当成创建顺序或提交顺序，在并发下会产生错误结果。多个事务可能先后取号却反向提交，失败语句也可能留下空洞。展示排序应使用明确的时间字段并补充稳定决胜字段，不能根据编号连续性推断是否丢单。顺序编号也容易被猜到；即使另加不透明的公开标识，授权仍必须检查请求者与资源之间的关系，不能靠“不容易猜”保护数据。

导入时覆盖 identity 是另一种陷阱。插入的显式编号远大于序列当前位置，序列仍可能继续从较小值生成，最终碰到已有主键。应在受控导入流程中协调序列状态，并排除或正确协调并发写入。另开一个会话查询 max(id) 再加一，不是并发安全的分配算法；两个调用方可能同时得到相同结果。

迁移还可能意外删掉原自然键承担的唯一规则。换键之前要检查重复值与 null，保留真正需要的业务唯一约束，并沿所有真实引用更新。也不必仅因代理键常见就给每张表增加一列和一个索引；稳定自然键如果已经准确表达契约，也可能是合适选择。决策依据应是业务值的可变性、引用范围和数据语义。

外键不会自动为引用方字段建立索引。users 主键支持检查客户是否存在，但查找这个客户的订单是另一条访问路径。应根据实际关联，以及父行更新或删除时的检查需要，评估 orders.user_id 上的索引；不能因为写了 REFERENCES，就推断子表索引也已创建。这个区别在引用数量增长后尤其值得检查。

快速验证

把下面代码保存为 identity.sql，运行 psql -X -v ON_ERROR_STOP=1 -f identity.sql，连接一个可丢弃的 PostgreSQL 18 数据库。实验使用临时表并在末尾回滚，不依赖已有 users 表，也不需要读取真实用户邮箱。所有地址都采用保留的 example.test 域名，仅用于构造可重复的数据。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE users (
 id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 email text NOT NULL UNIQUE
);
CREATE TEMP TABLE orders (
 id integer PRIMARY KEY,
 user_id bigint NOT NULL REFERENCES users(id)
);
INSERT INTO users(email) VALUES ('a@example.test') RETURNING id AS owner_id \gset
INSERT INTO orders VALUES (1, :owner_id);
UPDATE users SET email='renamed@example.test' WHERE id=:owner_id;
SELECT u.id, u.email FROM orders o JOIN users u ON u.id=o.user_id;
DO $$ BEGIN
 INSERT INTO users(email) VALUES ('renamed@example.test');
 RAISE EXCEPTION 'duplicate email accepted';
EXCEPTION WHEN unique_violation THEN RAISE NOTICE 'duplicate email rejected';
END $$;
DO $$ BEGIN
 INSERT INTO users(id,email) VALUES (99,'manual@example.test');
 RAISE EXCEPTION 'explicit identity accepted without override';
EXCEPTION WHEN generated_always THEN RAISE NOTICE 'explicit identity rejected';
END $$;
INSERT INTO users(id,email) OVERRIDING SYSTEM VALUE VALUES (100,'import@example.test');
INSERT INTO users(email) VALUES ('next@example.test') RETURNING id;
DO $$ BEGIN
 IF (SELECT email FROM users u JOIN orders o ON u.id=o.user_id)
 IS DISTINCT FROM 'renamed@example.test' THEN
 RAISE EXCEPTION 'rename broke the reference';
 END IF;
 IF (SELECT id FROM users WHERE email='next@example.test') IS DISTINCT FROM 3 THEN
 RAISE EXCEPTION 'unexpected identity sequence position';
 END IF;
END $$;
ROLLBACK;

邮箱修改后，订单仍然关联到编号一的客户。重复邮箱被唯一约束拒绝，而这次失败插入已经消耗了序列值二。没有覆盖子句的显式 identity 插入被拒绝；受控覆盖随后写入编号一百，但下一条正常生成记录拿到的是三，说明显式导入没有重定位序列。代码同时断言引用仍然正确，以及这个隔离夹具中的具体序列结果。

这些 SQL 结果来自历史 PostgreSQL 18.6 单用户检查，本次没有重跑。psql 变量替换为实际观察到的一，未验证客户端 gset 行为。最后回滚清理实验对象，不能据此宣称普通业务事务中的序列不会有空洞。这个练习把生成机制、主键约束、外键完整性、业务唯一性与访问控制分开说明，避免把所有涉及 id 的规则都误认为由 identity 列自动完成。真正迁移时还要验证既有数据与并发写入流程，而不是只复制建表语句。

来源

PostgreSQL identity 列，生成模式与唯一性限制，已核验 2026-10-15。
PostgreSQL 约束，主键与引用完整性，已核验 2026-10-15。
PostgreSQL 序列函数，不随事务回滚的分配与空洞，已核验 2026-10-15。

查询变慢时同时检查计划与等待

Mon, 31 Jan 2028 00:00:00 +0000

一条过去很快的查询，可以在数据、统计和访问计划都没有变化时变慢。另一个事务可能持有它需要的锁，存储缓存可能比上次更冷，应用也可能在语句进入 PostgreSQL 之前就开始等待。重新检查计划很有用，但它应当放在完整的耗时比较中：先区分时间是花在执行工作上，还是花在等待获得执行机会。不能从“现在更慢”直接推导出“数据与统计一定都变了”。

保留可比较的基线

记录语句形状、有代表性的参数值、返回行数、相关会话设置，以及应用是否使用预备语句。不同参数可能命中完全不同规模的数据。手工使用常量的查询，不一定复现预备语句采用的通用计划；不同角色或搜索路径，也可能改变实际对象与权限。因此，拿一条看起来相似的语句作为对照，并不保证比较条件相同。

尽量在变慢正在发生时观察活动。pg_stat_activity 可以显示一个状态为运行中的查询正在等待锁；运行中并不等于持续消耗处理器。pg_blocking_pids 列出当前阻塞这个后端的会话。查看其他角色活动需要适当权限，因此字段不可见不等于没有工作发生。交互观察最好使用新的自动提交查询，而不是在同一个长事务中不断读取已经缓存的监控快照。

坏掉的样子

不加判断就运行 ANALYZE，相当于把每次变慢都当成统计陈旧。它可能增加维护工作，却完全没有解除真正的阻塞。一张只有一行的表，即使新增索引，也不能释放其他事务持有的行锁。准确的行数估计和很小的顺序扫描，可以与很长的应用等待同时存在；这两种观察并不矛盾。

EXPLAIN ANALYZE 会真正执行语句，写入也不例外，而且测量本身同样可能被阻塞。从生产环境复制一条大范围更新，不是无害的检查。应先看等待情况和锁的拥有者，再选择安全夹具或副作用已经明确的语句来测量。看到某个进程编号出现在阻塞列表中，也不能立即终止不熟悉的事务，因为它可能正在完成另一个有效业务操作。

没有锁等待的计划样本，也不等于端到端延迟。EXPLAIN ANALYZE 不会像普通查询那样把结果行发送给客户端；未指定 SERIALIZE 时，还不包含输出转换。TIMING OFF 减少逐节点计时开销，但仍保留总执行时间。大量结果传输、应用解码和连接池排队，需要在计划之外单独观察，不能从这里的执行时间中直接读出。

多会话过程归属于历史报告，未找回原始日志；打印观察需人工检查，超时是独立失败结果。

快速验证

打开三个新的 psql 会话，分别记作甲、乙、丙，连接同一个可丢弃的 PostgreSQL 18 数据库并使用相同角色，保留通常的自动提交行为。名为 query_recheck_demo 的模式必须尚不存在，集群中也不能有其他会话使用实验应用名称。角色须有权创建并移除模式，活动跟踪应已启用，且没有更短的锁超时。每个会话遇到非预期错误都应停止。务必区分会话：把所有代码块顺序粘贴到同一个连接，无法证明事务之间的阻塞。

在甲中建立夹具，然后开启事务，修改唯一一条记录但暂不提交。

\set ON_ERROR_STOP on
CREATE SCHEMA query_recheck_demo;
CREATE TABLE query_recheck_demo.items (id integer PRIMARY KEY,value integer);
INSERT INTO query_recheck_demo.items VALUES (1,0);
ANALYZE query_recheck_demo.items;

BEGIN;
UPDATE query_recheck_demo.items SET value=10 WHERE id=1;
SELECT pg_backend_pid() AS blocker_pid;

在乙中发起带执行测量的更新。它会等待甲结束事务，或者等到六十秒的语句超时。

SET application_name='xbcatm_recheck_waiter';
SET statement_timeout='60s';
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
UPDATE query_recheck_demo.items SET value=value+1 WHERE id=1;

乙仍在等待且尚未超时时，在丙中执行观察查询。实验专用应用名称用于定位乙，不需要展示整条查询文本。

SELECT pid,state,wait_event_type,wait_event,pg_blocking_pids(pid) AS blockers
FROM pg_stat_activity WHERE application_name='xbcatm_recheck_waiter';

回到甲，撤销尚未提交的变更并释放锁，然后收集乙执行完毕后的计划。

ROLLBACK;

确认乙已经成功结束后，在丙中检查最终数据并清理夹具。

SELECT value FROM query_recheck_demo.items WHERE id=1;
DROP SCHEMA query_recheck_demo CASCADE;

原文报告的 PostgreSQL 18.6 观察未在本轮重新执行，也未在保留的验证文件中找到原始多会话日志；其中描述乙的状态为运行中，等待类型是 Lock，具体等待事件是 transactionid，阻塞列表包含甲的进程编号。具体事件可能随争用过程变化，核心证据是乙确实被甲阻塞。该报告称甲回滚后，乙把零加成一，最后查询返回一，清理移除了模式。必须人工确认丙恰好识别出乙、阻塞列表包含甲报告的 pid，且最终值为一；SQL 只是打印这些观察，没有自动断言。

乙的扫描估计并读取一行；最上层 Update 节点实际返回零行，是因为没有 RETURNING 子句，不表示没有修改数据。总体执行时间包含人为制造的等待，长短取决于甲何时释放事务，不能把这个数字当作扫描一行的固有成本。如果乙先超时，就先回滚甲，并用丙的最后一个代码块清理夹具后再重新开始。取消的更新并不等同于成功加一，不能沿用成功情况的结果解释。错误或中断可能留下甲的事务与持久模式；应先结束实验事务，再只移除本次创建的模式。

顺着观察到的原因继续

如果证据指向锁等待，先调查事务持有时间和归属，再考虑访问路径。如果实际处理的行太多，则比较过滤选择率与当前统计。如果排序或哈希操作发生溢写，就检查内存和临时读写。最后还要把数据库执行时间与应用请求延迟比较，识别连接建立、连接池排队或客户端处理的部分。只有新计划能够解释测得的回归，并保持所需结果，计划变化才构成有效改进。

来源

PostgreSQL 18：监控数据库活动，活动会话与等待观察，已核验 2026-10-15。
PostgreSQL 18：使用 EXPLAIN，行数、循环次数与计划解读，已核验 2026-10-15。
PostgreSQL 信息函数，通过 pg_blocking_pids 识别阻塞会话，已核验 2026-10-15。

PostgreSQL 使用两层数据缓存

Thu, 27 Jan 2028 00:00:00 +0000

普通缓冲式关系文件读写中，PostgreSQL 的共享缓冲位于操作系统文件缓存之上。命中共享缓冲时，不需要再次通过下面的文件读取路径；没有命中时，也可能由操作系统直接从内存提供数据。同一文件内容可以在两层各有副本，所以这里并不承诺数据库与内核共用同一份物理内存，更不能把两层缓存理解为完全没有重复占用。mmap 共享内存配置针对共享区域，不能据此推断普通表文件被直接内存映射。

坏掉的样子

执行计划里的共享读取计数，表示块被读入 PostgreSQL 缓冲池，不证明存储设备实际执行了一次物理读取。如果把每次共享读取都算成磁盘未命中，已经温热的操作系统缓存也会被误认为冰冷，从而引出错误的内存配置判断。同样，第二次查询更快，也不能独自说明究竟是哪一层缓存发生了变化，或是否只是其他执行条件改变。

缓存驻留是临时状态。其他查询可能挤走页面，工作集超过容量时，也不能指望所有页永久留在内存里；关系扫描采用的缓冲策略还可能影响复用方式。因此应使用已知大小的工作集、检查实际访问路径，并把耗时结论与真正观察到的缓存层事实分开。没有设备层测量，就不能仅凭一个计划字段宣布磁盘速度发生了变化。

Postgres 有两层缓存：机制图。

快速验证

使用 PostgreSQL 18 可丢弃实例和超级用户，确保附带的缓冲观察与预热扩展可安装、且尚未安装。保留的较早运行使用 PostgreSQL 18.6 单用户后端及一百二十八兆字节共享缓冲。本次来源复核没有重跑；psql 传输与并发活动仍未验证。下面的数据可以轻松放下。通过一个全新的 psql -X -v ON_ERROR_STOP=1 会话按顺序执行。关系驱逐函数用于开发测试，这里只针对隔离实验创建的对象操作：

CREATE SCHEMA cache_layer_demo;
CREATE EXTENSION pg_buffercache WITH SCHEMA cache_layer_demo;
CREATE EXTENSION pg_prewarm WITH SCHEMA cache_layer_demo;
CREATE TABLE cache_layer_demo.items (id integer PRIMARY KEY,payload text)
 WITH (autovacuum_enabled=false);
INSERT INTO cache_layer_demo.items
SELECT g,repeat(md5(g::text),10) FROM generate_series(1,12000) AS g;
VACUUM (ANALYZE) cache_layer_demo.items;
CREATE VIEW cache_layer_demo.residency AS
SELECT count(*) AS heap_buffers FROM cache_layer_demo.pg_buffercache
WHERE reldatabase=(SELECT oid FROM pg_database WHERE datname=current_database())
 AND relfilenode=pg_relation_filenode('cache_layer_demo.items')
 AND relforknumber=0;
SET max_parallel_workers_per_gather=0;
SELECT pg_relation_size('cache_layer_demo.items')/current_setting('block_size')::int AS heap_blocks;
SELECT heap_buffers>0 AS initially_buffered FROM cache_layer_demo.residency;

本次构建的主堆有五百四十六个块，初始缓存比较返回真。观察视图限制数据库、文件标识与主分支，并假定这个新建实验只使用默认表空间。通用监控还必须区分表空间，因为文件编号不是数据库内跨表空间唯一的物理身份。每个缓冲条目的观察是一致的，但整个视图并不是同一瞬间的原子缓存快照。接着，仅驱逐这个关系的共享缓冲：

SELECT * FROM cache_layer_demo.pg_buffercache_evict_relation('cache_layer_demo.items'::regclass);
SELECT heap_buffers=0 AS no_shared_heap_buffers FROM cache_layer_demo.residency;

函数返回驱逐、刷出和未能驱逐的数量，本次分别为五百五十、五百五十和零。总数包含辅助分支，所以比只统计主堆的块数更大。后面的比较确认主堆共享缓冲已为空，但这个结果没有回答操作系统里是否仍然缓存着同一批文件页面。两层的状态需要分别观察，不能从一层为空推断另一层也为空。

通过操作系统同步读取主堆，但不把内容加载进数据库共享缓冲：

SELECT cache_layer_demo.pg_prewarm('cache_layer_demo.items','read','main');
SELECT heap_buffers=0 AS still_no_shared_heap_buffers FROM cache_layer_demo.residency;

预热函数处理了五百四十六个块，共享缓冲数量仍是零。这里选择的是同步读取模式；若改用缓冲模式，就会把页加载到数据库缓冲池。现在执行一个需要访问全部载荷的查询：

EXPLAIN (ANALYZE,BUFFERS,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
SELECT sum(length(payload)) FROM cache_layer_demo.items;

顺序扫描报告五百四十六次共享读取，共享命中为零。这与操作系统缓存已经温热完全相容，不能把它翻译成五百四十六次设备读操作。再执行同样的查询：

EXPLAIN (ANALYZE,BUFFERS,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
SELECT sum(length(payload)) FROM cache_layer_demo.items;

第二次扫描共享读取为零，共享命中为五百四十六。两次都处理一万两千行，所以缓冲计数变化并不是因为查询少读了业务记录。最后核对驻留状态和聚合结果，再清理实验与扩展：

SELECT heap_buffers>0 AS now_shared FROM cache_layer_demo.residency;
SELECT sum(length(payload)) FROM cache_layer_demo.items;
RESET max_parallel_workers_per_gather;
DROP SCHEMA cache_layer_demo CASCADE;

载荷字符总数应为三百八十四万，共享驻留比较为真。精确块数取决于行布局和构建参数；关键观察是同步预热后共享缓冲仍为空，首次查询发生共享读取，再次查询转为命中。这些结果没有测量设备延迟，也不保证某个固定倍数的加速。用它们说明缓存层次是合适的，用来预测生产查询耗时则证据不足。

为整个服务器分配内存

资源配置文档对内存充足的专用服务器，给出了共享缓冲约占系统内存四分之一的起始建议，但这不是任何负载都最优的常数。连接本身、并发排序与哈希、维护任务，以及操作系统缓存，都在使用同一个主机预算。只增加一层的容量，可能把其他工作所需的余量挤掉，因此不能孤立地看共享命中率决定配置。

修改之前应测量有代表性的工作集与并发请求。全部缓存已经温热的微型测试会隐藏读写压力，完全冷启动测试又可能夸大平时高度复用页面的负载代价。把缓存层计数、设备层观察和查询结果结合起来，才能把配置调整的收益归到它实际改变的那一部分，而不是把所有内存读取都叫作磁盘优化。

来源

PostgreSQL 18 资源消耗，共享缓冲与操作系统缓存的内存预算，已核验 2026-10-15。
PostgreSQL 18 pg_prewarm，同步读取和数据库缓冲预热模式，已核验 2026-10-15。
PostgreSQL 18 pg_buffercache，缓冲身份及开发测试用的关系驱逐函数，已核验 2026-10-15。
PostgreSQL 文件布局，数据库、表空间与关系文件身份，已核验 2026-10-15。

哈希索引复核碰撞，也要维护变化的键

Mon, 24 Jan 2028 00:00:00 +0000

PostgreSQL 哈希索引先利用哈希码缩小等值查询的候选范围，再回到表中核对原始值。哈希匹配只说明“可能相等”，不能直接证明相等。两个不同值可能具有相同哈希码，不同哈希码也可能映射到同一个桶。正常复核存在时，碰撞和共享桶都不意味着查询会返回错误结果；它们是实现需要处理的普通情况，而不是可以忽略的例外。

桶里究竟保存什么

索引条目包含四字节哈希值和指向表元组的引用，不保存完整的被索引列值。桶映射把查询导向相关索引页面。桶是共享存储空间，并不是给每个不同键单独分配一个专属位置。一个桶的主页装满后，可以继续连接溢出页，查询这个桶时也需要访问这些页面。因此，“一次算出桶”不等于“永远只读取一个页面”。

PostgreSQL 可以在单个索引页内部按哈希码排序，以便加速局部搜索，但这不会提供原始列值的顺序。哈希索引不能满足键范围或有序输出，只支持单列等值访问，不能强制唯一性，也不支持 IS NULL。B-tree 仍然可以服务等值查询，同时支持更广的一组操作，不能因为键看起来适合哈希就自动排除其他候选。

由于条目中没有原始值，哈希扫描是有损候选扫描，需要用表中实际值复核。因此，碰撞可以在执行计划中表现为 Rows Removed by Index Recheck。这说明数据库正确剔除了只在哈希上匹配的候选，而不是把两个碰撞值都当成相等返回。解读这项指标时，应把候选数量与最终答案区分开。

坏掉的样子

把索引键更新描述为“只碰一个桶”，掩盖了实际工作。修改被索引列会改变元组对应的索引值，新条目可能进入另一个桶。PostgreSQL 使用行版本与延后索引清理，旧引用不一定立刻从结构中消失。数据增长还可能触发桶分裂，溢出页也会增加读写。因此不能用一个理想化的哈希表赋值过程来解释数据库的全部更新成本。

高度重复的值、快速增长的表，与近乎唯一而稳定的等值负载，表现可能很不一样。哈希查询不是无条件的恒定延迟承诺。现代 PostgreSQL 的哈希索引支持崩溃恢复，但持久性既不会消除维护成本，也不会让它突然具备唯一性约束能力。读性能、写维护和数据契约必须分别确认。

同码与同桶不同；形状仅为示意。历史具体碰撞未找回原始日志，也未重跑。

快速验证

在可丢弃的 PostgreSQL 18 数据库中，用全新的 psql 会话执行下面代码；任何 SQL 或 psql 元命令错误都应停止。它建立二十万个采用 C 排序规则的临时文本键，使用当前服务器自己的 hashtext 找到一组碰撞，再验证等值查询和键更新。实验没有把哈希码当成跨版本稳定的业务标识，最后回滚会移除所有夹具。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE hash_items (key text COLLATE "C");
INSERT INTO hash_items SELECT 'key-'||g FROM generate_series(1,200000) AS g;
CREATE TEMP TABLE collision_pair AS
SELECT min(key) AS a,max(key) AS b FROM hash_items
GROUP BY hashtext(key) HAVING count(*)>1 ORDER BY hashtext(key) LIMIT 1;
SELECT a AS collision_a,b AS collision_b FROM collision_pair \gset
SELECT a,b,hashtext(a),hashtext(b) FROM collision_pair;
CREATE INDEX hash_items_key ON hash_items USING hash(key);
ANALYZE hash_items;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT key FROM hash_items WHERE key=:'collision_a';
UPDATE hash_items SET key='changed-'||key WHERE key=:'collision_a';
SELECT count(*) AS old_key_rows FROM hash_items WHERE key=:'collision_a';
SELECT count(*) AS new_key_rows FROM hash_items WHERE key='changed-'||:'collision_a';
DO $$ BEGIN
 IF (SELECT hashtext(a)=hashtext(b) AND a<>b FROM collision_pair) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'fixture did not establish a collision';
 END IF;
 IF (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key=p.a) <> 0 OR
 (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key='changed-'||p.a) <> 1 OR
 (SELECT count(*) FROM hash_items h JOIN collision_pair p ON h.key=p.b) <> 1 THEN
 RAISE EXCEPTION 'hash lookup or indexed update returned wrong keys';
 END IF;
END $$;
ROLLBACK;

历史文章记录称 PostgreSQL 18.6 找到的两个键是 key-129539 与 key-7295，哈希码都是 -1960436116。等值计划使用 hash_items_key，最终只返回一行，同时报告一行被索引复核移除。两段字符串虽然哈希相同，却仍然是不同的值。这属于历史文章报告的负向验证；本轮没有重跑，也未在保留的验证文件中找到原始碰撞日志。普通无碰撞点查不能替代这一检查。

将第一个键改成带 changed- 前缀的新值后，旧值查到零行，新值查到一行，另一条碰撞记录仍然查到一行。最终断言分别验证这三件事，并确认原始两个值确实具有相同哈希而内容不同。仅仅看到更新命令成功，还不足以证明同桶或同哈希的其他记录没有受到错误影响。

具体碰撞键和计划形状来自这一版本的实测。如果其他环境没有找到碰撞对，脚本应停止，不能宣称已经验证碰撞复核。即使换个环境找到另一组键，语义要求仍然不变：精确相等只能返回原始值符合条件的记录；修改一个值，不得因为另一个值哈希相同而改变它。固定的结果契约比固定某个内部哈希码更重要。

把维护也放进性能评估

使用有代表性的分布一起测量页面访问、等值延迟、更新行为和索引大小。VACUUM 可以移除失效引用、回收溢出页供结构内部复用，但不会缩小哈希索引的桶数量，也不会把这部分分配直接归还操作系统。重建属于另外的维护操作，本身需要成本。较小的哈希条目确实可能有价值，但只有完整负载比较才能判断它是否抵得过复核、溢出页和写维护开销。

来源

PostgreSQL 18：哈希索引，碰撞复核与桶维护，已核验 2026-09-10。
PostgreSQL 18：索引类型，B-tree 与哈希索引支持的条件，已核验 2026-09-10。

LATERAL 让每一行都有自己的子查询窗口

Wed, 19 Jan 2028 00:00:00 +0000

LATERAL 允许 FROM 中的一个项目引用它前面项目提供的列。每个父记录需要一个带自身参数的小结果集时，它很实用，例如每位客户最近的两笔订单。整个查询仍是一条 SQL、一次数据库往返，横向子查询明确表达哪些外层值决定当前结果。但这种逻辑关系不承诺唯一的物理执行策略，规划器仍可进行保持语义的优化。

把关联条件写清楚

普通 FROM 子查询不能随意引用旁边表的列，LATERAL 允许在合适的连接位置使用这些引用。o.customer_id = c.id 才是当前客户与订单之间的关联；只写关键词不会自动产生这个条件。如果删除关联，每位客户可能都拿到同一份全局结果。语法通过只能证明语句合法，不能证明取到的是这个客户自己的订单。

实现每组前几名时，把父记录过滤条件、ORDER BY 和 LIMIT 都放进横向子查询。放在整个连接外面的 LIMIT 限制的是最终组合结果，不是每位客户最多几笔订单。排序还需要唯一的决胜字段：两笔订单完全可能具有相同时间戳，只按时间排序时，边界位置选择哪一行没有保证，换一个计划就可能换一个答案。

子查询里的 ORDER BY 决定入选哪些行，并不保证最终结果的展示顺序。客户端要求稳定的客户与订单顺序时，还需要外层 ORDER BY。导出报表和自动化检查尤其依赖这一点；不能因为当前执行计划碰巧按某个顺序返回，就把这种偶然表现当成接口契约，否则升级或统计信息刷新后会出现难以解释的行顺序变化。

决定没有匹配时保留什么

CROSS JOIN LATERAL 在子查询没有返回行时会丢掉对应父记录。LEFT JOIN LATERAL 配合 ON true 则保留父记录，并把右侧列补成 null。对尚未下单的客户，后者往往才符合页面或报表需求。如果把右侧条件移到外层 WHERE，补出来的 null 行可能被过滤掉，原本想保留空客户的行为就被破坏了。

聚合还有一层区别。COUNT(r.id) 只统计非空订单标识，COUNT(*) 连左连接补出的那一行也会计算。没有 GROUP BY 的相关聚合，即使输入为空也可能返回一行，COUNT 是零，SUM 则是 null。因此不能把所有 LATERAL 表达式都理解成同一种列表查询，必须看它实际返回零行、一行还是多行，以及每一列的空值含义。

坏掉的样子

一种危险的“修复”是为了消除外层引用的语法错误，直接删除关联条件。查询之后正常运行，但每位客户都获得全站最近的订单，汇总数字被放大仍可能看起来合理。测试应覆盖没有订单、只有一笔、有多笔以及时间相同的客户。断言确切订单标识比只验证查询成功更有价值，因为它能发现归属错误与排序边界错误。

另一种问题是昂贵的内层操作随着外层行数反复执行。以关联键开头、后接所需排序字段的索引，可以支持选择性较高的 top-N 查找，但不保证一定被选择，小表尤其如此。查看 EXPLAIN 的 actual loops 和行数，外层涉及大量客户时还应比较窗口函数方案。LATERAL 消除的是客户端逐个查询的往返，不会让数据库内部的工作量凭空消失。

每个父记录选择自己的行。依据文章示例与明确限制静态绘制；未为本图执行 SQL。

快速验证

将下面代码保存为 lateral.sql，使用 psql -X -v ON_ERROR_STOP=1 -f lateral.sql 连接一个可丢弃的 PostgreSQL 18 数据库。实验在一个事务中创建三位客户、四笔订单、匹配的索引和临时视图，所有数据都在代码中给出，不依赖已有业务表，也不需要猜测字段含义。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL statement_timeout = '5s';
CREATE TEMP TABLE customers (id integer PRIMARY KEY, name text);
CREATE TEMP TABLE orders (id integer PRIMARY KEY, customer_id integer, placed_at date);
INSERT INTO customers VALUES (1,'Ada'), (2,'Lin'), (3,'Sam');
INSERT INTO orders VALUES
 (10,1,'2026-09-01'), (11,1,'2026-09-02'), (12,1,'2026-09-02'),
 (20,2,'2026-09-01');
CREATE INDEX orders_recent ON orders (customer_id, placed_at DESC, id DESC);
ANALYZE customers;
ANALYZE orders;
CREATE TEMP VIEW recent AS
SELECT c.id AS customer_id, r.id AS order_id
FROM customers c LEFT JOIN LATERAL (
 SELECT o.id FROM orders o WHERE o.customer_id=c.id
 ORDER BY o.placed_at DESC, o.id DESC LIMIT 2
) r ON true;
SELECT * FROM recent ORDER BY customer_id, order_id DESC;
SELECT c.id, count(r.id) AS selected_orders
FROM customers c LEFT JOIN LATERAL (
 SELECT o.id FROM orders o WHERE o.customer_id=c.id
 ORDER BY o.placed_at DESC, o.id DESC LIMIT 2
) r ON true GROUP BY c.id ORDER BY c.id;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT * FROM recent;
DO $$ BEGIN
 IF (SELECT array_agg(order_id ORDER BY order_id) FROM recent WHERE customer_id=1)
 IS DISTINCT FROM ARRAY[11,12] THEN
 RAISE EXCEPTION 'top two or tie-breaker is wrong';
 END IF;
 IF NOT EXISTS (SELECT FROM recent WHERE customer_id=3 AND order_id IS NULL) THEN
 RAISE EXCEPTION 'LEFT JOIN lost the customer without orders';
 END IF;
 IF (SELECT count(*) FROM recent) <> 4 THEN RAISE EXCEPTION 'wrong row count'; END IF;
END $$;
ROLLBACK;

结果依次包含 (1,12)、(1,11)、(2,20)，以及第三位客户配一个 null 订单。匹配订单数量分别是二、一、零。十一和十二号订单虽然日期相同，但两行都能进入限额，因此这个夹具没有验证恰好跨过 LIMIT 边界时如何排除某条并列行；第三位客户验证没有匹配时是否仍然保留。断言检查具体标识和总行数，最后的回滚移除全部临时对象。

PostgreSQL 18.6 在这份四笔订单的夹具上使用了重复的小表扫描，这很合理，不能据此断定设计中的索引在大数据量下无效。反过来，也不能因为建了索引就要求任何计划都显示索引扫描。性能结论需要接近真实的客户数量和订单分布，正确性结论则来自关联条件、连接类型与确定排序。五秒 statement timeout 为实验单条语句设定执行上限，并不代替生产负载评估。

来源

PostgreSQL 表表达式，横向引用与外连接语义，已核验 2026-10-15。
PostgreSQL SELECT，排序与 LIMIT 行为，已核验 2026-10-15。

pg_dump 拍一张一致的快照

Fri, 14 Jan 2028 00:00:00 +0000

pg_dump 使用事务数据的一致视图导出一个 PostgreSQL 数据库，同时允许其他会话继续提交变化。它避免了普通逐表复制的问题：前一张表和后一张表不会因为读取时间不同，就混入彼此不一致的已提交状态。但快照只是备份契约的一部分；归档还必须覆盖需要的数据范围，能被兼容工具读取，并且实际恢复成可使用的数据库。

理解快照覆盖什么

导出期间，快照可见的行构成稳定视图。后续提交不会因为某张表读得晚，就逐渐混进同一次导出。并行导出让各 worker 使用同步快照，而不是各自随时读取。并行 dump 要求 directory 格式；custom 格式支持并行恢复，但不支持并行导出。格式选择应根据导出与恢复两边的需求分别判断，不能把两个方向混为一谈。

数据库快照不会自动让整个业务流程原子化。如果应用分两个事务提交批次头和明细，一致快照完全可能合法地落在这两次提交之间。序列状态也不是普通的 MVCC 行数据，外部文件和其他服务更不在数据库快照范围内。恢复需要满足什么业务不变量，必须结合真实事务边界和所需数据源定义，不能只凭“同一快照”推断所有业务状态都完整。

计算负载和依赖

普通读取和写入通常可以在导出期间继续，但 pg_dump 仍获取 ACCESS SHARE 锁，也消耗 CPU、I/O、连接和快照存活时间。冲突的 DDL 可能等待，也可能使导出失败；长快照会阻止某些旧行版本被清理。增加并行 worker 只是用更多并发资源换时间，不会让备份开销消失。应记录事务年龄和线上负载，避免把备份的影响误认为无关故障。

使用备库可以分担读取，但要考虑恢复冲突与复制延迟，而且从备库导出会排除非日志表内容。一次 pg_dump 也不包含集群级角色和表空间。扩展、所有者、权限、排序规则行为及目标配置，都需要通过合适机制纳入恢复计划。把整个库拆成互不协调的单表 dump，可能丢失共同快照，也可能遗漏这些表依赖的对象，不能当成免费的优化。

坏掉的样子

归档目录能够列出，不代表恢复一定成功。目标缺少角色或扩展时，表数据可能只恢复了一部分。应把归档加载到隔离空库，明确处理错误，再验证业务不变量和代表性查询。pg_restore 默认遇到 SQL 错误仍会继续，最后汇总错误数量；只看到最后一条查询有输出是不够的。小型演练可使用单事务恢复获得原子性，但这个模式不能与并行 job 同用。

工具版本是另一条边界。pg_dump 客户端会拒绝比自身主版本更新的服务器，输出主要面向相同或更新的目标版本，不能保证可以加载到更旧的主版本。应核对客户端、源库、目标库、扩展和恢复选项的实际组合，而不是只说“都是 PostgreSQL 所以可以恢复”。即使语法兼容，排序规则或权限差异也可能改变应用行为。

逻辑导出可以满足经测量确认的恢复目标，但不能任意重放到两次导出之间的时刻。物理基础备份加完整保留的 WAL 链，才提供对应的时间点恢复路径。导出间隔是否可接受，取决于允许的数据丢失窗口和恢复时间，不存在“短于一天就一定不行”的统一阈值。必须按实际要求设计留存与恢复链条。

导入的事务快照恢复较早的一组关联数据，而源库已有两组。逻辑导出仍需依赖和恢复检查，也不能充当物理 WAL 重放起点。

快速验证

把 Bash 代码保存为 dump.sh。它自行创建实验 PostgreSQL 集群，并在退出时删除。可以用非 root 用户运行 PostgreSQL 18 工具，也可以使用下面的隔离容器；命令不发布网络端口，不挂载宿主机数据。两个数据库、归档和成功标记都只存在于实验临时目录及集群中。

docker run --rm --network none --user postgres --entrypoint bash -i \
 postgres:18-alpine < dump.sh

#!/usr/bin/env bash
set -euo pipefail
dump_lab=$(mktemp -d /tmp/pgdump-lab.XXXXXX)
cleanup() {
 if [ -f "$dump_lab/data/postmaster.pid" ]; then
 pg_ctl -D "$dump_lab/data" -m fast -w stop >/dev/null
 fi
 rm -rf -- "$dump_lab"
}
trap cleanup EXIT
initdb -D "$dump_lab/data" --no-locale --encoding=UTF8 --auth=trust >/dev/null
pg_ctl -D "$dump_lab/data" -l "$dump_lab/server.log" \
 -o "-k $dump_lab -p 55432 -c listen_addresses=''" -w start >/dev/null
export PGHOST="$dump_lab" PGPORT=55432 PGDATABASE=source_db
export DUMP_FILE="$dump_lab/source.dump" DUMP_OK="$dump_lab/dump-ok"
createdb source_db
createdb restored_db
psql -X -v ON_ERROR_STOP=1 <<'SQL'
CREATE TABLE customers (id integer PRIMARY KEY, name text);
CREATE TABLE orders (id integer PRIMARY KEY, customer_id integer REFERENCES customers(id));
INSERT INTO customers VALUES (1,'before');
INSERT INTO orders VALUES (10,1);
BEGIN ISOLATION LEVEL REPEATABLE READ READ ONLY;
SELECT pg_export_snapshot() AS snapshot_id \gset
\setenv DUMP_SNAPSHOT :snapshot_id
\! psql -X -v ON_ERROR_STOP=1 -c "BEGIN; INSERT INTO customers VALUES (2,'after'); INSERT INTO orders VALUES (20,2); COMMIT;" && pg_dump --format=custom --snapshot="$DUMP_SNAPSHOT" --file="$DUMP_FILE" && touch "$DUMP_OK"
COMMIT;
SQL
test -f "$DUMP_OK"
pg_restore --list "$DUMP_FILE" > "$dump_lab/archive-list"
pg_restore --exit-on-error --single-transaction --dbname=restored_db "$DUMP_FILE"
counts='SELECT (SELECT count(*) FROM customers), (SELECT count(*) FROM orders)'
test "$(psql -X -Atc "$counts")" = '2|2'
test "$(psql -X -d restored_db -Atc "$counts")" = '1|1'
test "$(psql -X -d restored_db -Atc 'SELECT count(*) FROM orders o LEFT JOIN customers c ON c.id=o.customer_id WHERE c.id IS NULL')" = 0
psql -X -d restored_db -v ON_ERROR_STOP=1 -c \
 'SELECT c.name,o.id FROM customers c JOIN orders o ON o.customer_id=c.id'
pg_dump --version
printf 'PASS: source=2|2 restored=1|1 orphan_orders=0\n'

第一个会话导出快照时，库中只有一位客户和一笔订单。在该事务保持打开时，第二个会话提交另一组有关联的数据。pg_dump 明确导入较早快照，所以恢复后计数是 1|1，源库当前计数则为 2|2。关联查询返回名为 before 的客户和十号订单，悬空订单检查结果为零。这样验证的是确定的并发时序，不依赖导出恰好跑得够慢。

PostgreSQL 18.6 上完整恢复与断言均通过。嵌套 shell 只有在写入和 dump 都成功后才创建标记，防止 psql 在外部命令失败后继续运行而掩盖失败。这个实验验证夹具中的快照选择和恢复，不代表已经测出真实应用的恢复时间。生产备份仍需保留实际恢复演练、归档校验值、留存策略与依赖记录，才能让一次成功导出成为可审阅的恢复能力。

来源

PostgreSQL pg_dump，快照、格式、范围与版本兼容，已核验 2026-09-10。
PostgreSQL pg_restore，恢复错误处理和事务选项，已核验 2026-09-10。

PostgreSQL 时间函数取样于不同的时点

Thu, 13 Jan 2028 00:00:00 +0000

PostgreSQL 提供多种“当前时间”。事务时间标记事务开始，语句时间标记客户端命令到达，墙钟读数则在表达式求值时读取当前时钟。选择不同函数，会改变审计字段、过期检查和长任务中间观测的含义。应先明确要记录哪个事件，再决定函数，不能因为名称都有时间含义就随意互换。

一个事务只有一个开始时刻

now()、transaction_timestamp() 与不带精度参数的 CURRENT_TIMESTAMP，返回同一个事务开始瞬间。在显式事务里，它们始终固定，即使后续语句已经晚了几秒或几分钟。CURRENT_TIMESTAMP 可以指定精度来舍入结果；小数位数的处理与采样时刻是两回事，不能因为显示精度不同就推断时钟来源改变。

这种稳定性适合让相关行共享同一个逻辑事务时间。它不记录每行真正插入的时刻，也不是最终提交时间。事务可能先等待锁或执行大量计算，随后才插入数据，最后还有可能回滚。把列命名为 created_at，并不能自动说明默认值到底代表哪个事件，需要在数据契约里写清楚。

普通自动提交模式下，连续语句通常各自处于不同事务，因此 now 看起来会随每条语句前进。但这种观察没有改变函数契约。后来为了原子性加上显式事务时，原本被误认为实时变化的时间，就可能暴露出早已固定的问题；验证时应覆盖真实事务边界，而不只在交互终端连续敲两条查询。

语句标记与实时读数

statement_timestamp() 返回服务器收到最近一条客户端命令消息的时间，在该命令执行期间保持稳定。事务中后续命令的语句时间可能与事务时间不同。同一协议消息里发送的多条 SQL 命令，也可能共享这个标记，所以它不一定代表等待结束后，每个内部操作真正开始的那一刻。

clock_timestamp() 在求值时读取当前墙钟，即使同一条语句内部也可能变化。由于时钟精度有限，两次调用并不保证得到不同值。它也不是单调计时器，时钟校正可能影响前后读数的差值。需要保证耗时测量不受墙钟调整影响时，应使用合适的单调时钟，而不是把数据库墙钟当成无条件递增的计数器。

这些值单独使用，都不能证明并发事务的提交顺序，也不能提供唯一事件身份。相关字段需要一致逻辑时间时选事务标记，观测命令到达时选语句标记，需要读取当前墙钟时才选实时观测。身份与顺序要求应另外明确，不能让时间戳自动承担它未承诺的语义。

坏掉的样子

长事务中的过期检查如果使用 now，就会持续与事务开始时刻比较。一个在事务开始时成立的条件，即使真实墙钟已经越过截止时间，也可能继续成立。即便使用 clock_timestamp，也只检查求值瞬间，不能保证稍后的提交仍在截止时间之前。要求提交时有效的业务规则，需要另外设计并发与时间边界。反过来，把全部默认值换成 clock_timestamp，又可能让本该共享逻辑创建时间的相关行各不相同。修改函数前，应先确定列代表的是业务批次、命令到达还是实际观测。

列默认值中的特殊字面量 TIMESTAMPTZ 'now' 也是一个陷阱。PostgreSQL 在解析常量时就把它转换成时间，所以后续插入可能一直拿到建表时刻。DEFAULT now() 是函数调用，会在真正使用默认值时求值。两种写法看起来相似，并不代表求值生命周期相同；只检查默认表达式包含 now 这个词，会漏掉这个差别。

这些函数返回 timestamptz。切换会话时区会改变瞬间的显示形式，而不是改变已存储的瞬间本身。timestamptz 不保留最初传入的时区名称；应用需要记住原始时区时，应单独建模，不能从后来显示的偏移量反推原始地区。相同偏移量也不足以唯一确定某个时区名称。

三类时间，三个取样时点。依据文章示例与明确限制静态绘制；未为本图执行 SQL。

快速验证

把下面内容保存为 timestamps.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f timestamps.sql。显式事务之外，应保持 psql 默认的自动提交行为；第二段需要让两次插入分别处在不同事务里。所有表都是临时表。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL timezone='UTC';
CREATE TEMP TABLE moments (step integer,tx timestamptz,statement timestamptz,wall timestamptz);
INSERT INTO moments VALUES (1,now(),statement_timestamp(),clock_timestamp());
SELECT pg_sleep(0.03);
INSERT INTO moments VALUES (2,CURRENT_TIMESTAMP,statement_timestamp(),clock_timestamp());
SELECT step,tx,statement,wall FROM moments ORDER BY step;
SELECT min(tx)=max(tx) AS one_transaction_time,
 count(DISTINCT statement)=2 AS two_statement_times FROM moments;
SELECT now()=transaction_timestamp() AND now()=CURRENT_TIMESTAMP AS aliases;
SELECT extract(epoch FROM now()) AS instant_utc;
SET LOCAL timezone='Asia/Shanghai';
SELECT now() AS same_instant_different_display,extract(epoch FROM now()) AS instant_shanghai;
DO $$ BEGIN
 IF (SELECT min(tx)=max(tx) FROM moments) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'transaction time changed';
 END IF;
 IF now() IS DISTINCT FROM transaction_timestamp() THEN RAISE EXCEPTION 'aliases differ'; END IF;
 IF (SELECT tx FROM moments WHERE step=1) IS DISTINCT FROM now() THEN
 RAISE EXCEPTION 'time zone changed the instant';
 END IF;
END $$;
ROLLBACK;
CREATE TEMP TABLE defaults_demo (
 id integer,
 parsed timestamptz DEFAULT TIMESTAMPTZ 'now',
 called timestamptz DEFAULT now()
);
INSERT INTO defaults_demo (id) VALUES (1);
SELECT pg_sleep(0.03);
INSERT INTO defaults_demo (id) VALUES (2);
SELECT id,parsed,called FROM defaults_demo ORDER BY id;
SELECT min(parsed)=max(parsed) AS one_parsed_constant,
 count(DISTINCT called)=2 AS two_insert_transaction_times FROM defaults_demo;
DO $$ BEGIN
 IF (SELECT min(parsed)=max(parsed) FROM defaults_demo) IS DISTINCT FROM true THEN
 RAISE EXCEPTION 'parsed default was evaluated again';
 END IF;
END $$;
DROP TABLE defaults_demo;

本轮 PostgreSQL 18.6 单用户重跑将命令分别输入，前两行共享相同 tx，但 statement 和 wall 读数不同；未测试 psql 客户端协议。别名比较返回真。从 UTC 切换到 Asia/Shanghai 后，显示偏移变成东八区，但两次 epoch 值完全一致。断言检查事务时间稳定，并确认时区切换没有改变同一个瞬间，而不是仅凭显示字符串判断。

回滚第一段后，默认值实验在两个独立事务中分别插入一行。两行 parsed 保留相同的解析期常量，而 called 随插入事务变化。短暂休眠是为了让本次差别容易观察，并不保证时钟分辨率或调度延迟。最后的 DROP 清除第二张临时表；如果断言提前终止，连接结束也会清理临时对象，实验不会留下持久业务数据。

来源

PostgreSQL 日期时间函数，事务、语句、墙钟和默认值求值语义，已核验 2026-10-15。
PostgreSQL 日期时间类型，timestamptz 存储、显示和特殊输入字面量，已核验 2026-10-15。

checkpoint 把脏缓冲刷到磁盘

Thu, 06 Jan 2028 00:00:00 +0000

检查点为 PostgreSQL 崩溃恢复建立一个可用起点。它同步这个检查点所需的数据文件变更，并记录相应恢复信息。依赖某段日志的数据页写出之前，相关 WAL 必须先持久化。这样的顺序让事务提交不必每次都把全部修改过的表页立即刷到磁盘；发生崩溃时，再从恢复起点重放后续必要变更。

坏掉的样子

检查点不是事务提交。数据页可以包含尚未提交事务写入的版本，读者究竟能看到哪些行，仍然由可见性与事务状态决定。检查点完成，不会把这些写入变成已提交，也不会把随手复制一份正在变化的数据目录变成有效基础备份。并发活动还可能再次弄脏页面，所以不能把完成提示理解成缓冲池从此全部干净。

日志保留也有别的限制。最大 WAL 大小是与自动检查点调度有关的软目标，不是磁盘使用硬上限；归档失败或复制槽保留，都可能让日志超过这个值。最小 WAL 大小则涉及回收并预留文件供以后复用，不是另一条强制触发检查点的阈值。如果理解错这些参数，可能一边看到检查点间隔正常，一边忽略实际上还在持续增长的归档积压。

维护进度与事务可见性分开；最终值 11 有断言，检查点比较是观察。双会话运行仍待验证。

快速验证

准备一台安静的 PostgreSQL 18 可丢弃实例，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。显式检查点和控制文件信息使用具有相应权限的管理角色。保留正常开启的同步落盘与同步提交设置。乙先创建计数器，并保存当前检查点位置：

SHOW fsync;
SHOW synchronous_commit;
CREATE SCHEMA checkpoint_demo;
CREATE TABLE checkpoint_demo.items (id integer PRIMARY KEY,n integer);
INSERT INTO checkpoint_demo.items VALUES (1,10);
CREATE TABLE checkpoint_demo.baseline AS
SELECT checkpoint_lsn FROM pg_control_checkpoint();

显示的两个设置都应为开启，初始已经提交的值是十。甲在一个保持打开的事务中把它改成九十九：

BEGIN;
UPDATE checkpoint_demo.items SET n=99 WHERE id=1 RETURNING n;

甲从自己的更新得到九十九，但此时不要提交。乙请求检查点，并查看普通读者可见的值：

CHECKPOINT;
SELECT c.checkpoint_lsn>b.checkpoint_lsn AS checkpoint_advanced,
 (SELECT n FROM checkpoint_demo.items WHERE id=1) AS visible_value
FROM checkpoint_demo.baseline AS b CROSS JOIN pg_control_checkpoint() AS c;

检查点位置推进了，乙仍然读到十。维护工作已经完成，甲的事务却还没有决定提交还是回滚。这把数据库维护的进度与业务操作的提交状态明确区分开来，不能把其中一个完成信号当成另一个完成的证据。回到甲，核对自己的版本仍然可见，然后丢弃这次修改：

SELECT n FROM checkpoint_demo.items WHERE id=1;
ROLLBACK;

甲回滚前仍读到九十九。乙现在确认值恢复为原来的十，再完成一次普通提交，并在这次操作紧邻的位置记录前后检查点标识：

SELECT n FROM checkpoint_demo.items WHERE id=1;
UPDATE checkpoint_demo.baseline
SET checkpoint_lsn=(SELECT checkpoint_lsn FROM pg_control_checkpoint());
UPDATE checkpoint_demo.items SET n=11 WHERE id=1;
SELECT c.checkpoint_lsn=b.checkpoint_lsn AS no_new_checkpoint,
 (SELECT n FROM checkpoint_demo.items WHERE id=1) AS committed_value
FROM checkpoint_demo.baseline AS b CROSS JOIN pg_control_checkpoint() AS c;
DO $$ BEGIN
 IF (SELECT n FROM checkpoint_demo.items WHERE id=1) IS DISTINCT FROM 11 THEN
 RAISE EXCEPTION 'checkpoint/transaction boundary result mismatch';
 END IF;
END $$;
DROP SCHEMA checkpoint_demo CASCADE;

本次短调度的结果先是十，随后检查点未变化的比较为真，已经提交的值是十一。普通提交成功，并没有请求另一个检查点。在繁忙实例里，独立调度的检查点可能恰好改变这个比较结果，但不会改变提交本身的语义。断言核对最终行值，实验结束后删除自己的模式。

原演练报告的是事务可见性与检查点边界；本轮审阅没有重新执行双会话调度，没有测量恢复耗时，也没有模拟存储设备丢失已经确认写入的情况。持久性契约仍然依赖正确开启的相关设置，以及能够履行同步请求的存储。要判断实际恢复时间是否满足目标，需要另做基于真实保留工作量的崩溃恢复演练，不能从这几条查询完成得快直接推导出来。

同时考虑恢复与前台负载

延长检查点间隔，可能减少重复刷写，并在开启整页写入时减少一部分重复整页日志；崩溃后需要重放的工作也可能随之增加。检查点过于频繁，又可能提高日志和数据写流量，影响请求延迟。存储是快速本地磁盘，并不能单独证明更长的间隔就符合业务恢复目标，还是需要以测量作取舍。

完成目标参数把常规检查点工作分散到间隔中的某个比例，常用的九成是节奏目标，不是任何负载下都没有延迟尖峰的保证。应把检查点持续时间、请求触发与定时触发次数、日志增长和前台延迟结合起来看。累计计数应比较同一观察窗口内的增量，并检查 stats_reset；统计重置后数字变小，不代表工作量或故障已经改善。调小参数使任务更快完成，也可能意味着同一批写入挤在更短窗口里，不能只看完成时长缩短就认为代价下降。

在 PostgreSQL 18 中，检查点计数和写入、同步时间位于专门的检查点统计视图；后台写进程视图描述的是另一个组件。频繁由日志增长触发请求时，先判断是正常写入量、配置目标还是保留链路造成，再修改限额。最终应比较恢复测试和业务延迟，让调优结论对应实际达到的恢复能力，而不是只对应一个看起来整齐的参数值。

来源

PostgreSQL 18 WAL 入门，预写顺序及无需立即刷出所有数据文件的提交持久性，已核验 2026-10-15。
PostgreSQL 18 CHECKPOINT，显式检查点行为与所需权限，已核验 2026-10-15。
PostgreSQL 18 WAL 配置，检查点调度、写入节奏和日志大小语义，已核验 2026-10-15。
PostgreSQL 18 累计统计，专门的检查点统计视图，已核验 2026-10-15。

VACUUM FULL 重建一张表而不是修剪

Mon, 03 Jan 2028 00:00:00 +0000

大量删除之后，PostgreSQL 表可能只剩少量记录，却仍保留很大的文件。普通清理让旧空间可以在表内复用，完全清理则把存活内容写入新文件，同时重建索引。更彻底的空间回收，需要另一套锁与容量预算，应作为有计划的维护操作，而不是一看到文件大小偏高就立刻执行的日常反应。

坏掉的样子

重写需要的是 ACCESS EXCLUSIVE 表锁，普通读取和写入都与它冲突。某个查询虽然已经执行完，但事务仍然打开、继续持有表锁，也会挡住重写。把它叫成独占行锁，或者以为只有写请求受影响，会低估实际中断范围。排队等待重写的强锁请求，还可能影响随后进入的其他取锁请求，不能只看当前命令有没有开始复制数据。

替代文件成功建立之前，原文件仍然存在，所以操作需要额外磁盘空间。等文件系统已经写满才着手完全清理，可能反而没有容纳新文件的余量。应提前评估替代堆表与索引、磁盘读写和日志影响，以及能够承受的持锁时长。常规自动回收不会自动替你执行这类完整重写。

VACUUM FULL 需要冲突表锁和替代文件余量。SQLSTATE 断言提案仍未在双会话中执行；未声明生产耗时结果。

快速验证

早先审阅记录只报告在 PostgreSQL 18.6 单用户模式中执行了准备与成功压缩的 SQL 部分，双会话锁实验仍未执行；本轮源文审阅没有运行任何 SQL。

只有在获准的真实实验中，才在同一个 PostgreSQL 18 可丢弃数据库中开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。把乙的每个代码块存成文件，通过 \i 加载；任何脚本错误都必须停止整个练习。清理命令必须在显式事务块之外执行。乙先创建五千行、删除前四千五百行，然后进行普通清理：

CREATE SCHEMA compact_demo;
CREATE TABLE compact_demo.items (id integer PRIMARY KEY,payload text)
 WITH (autovacuum_enabled=false);
INSERT INTO compact_demo.items
SELECT g,repeat(md5(g::text),10) FROM generate_series(1,5000) AS g;
CREATE TABLE compact_demo.baseline AS
SELECT pg_relation_size('compact_demo.items') AS heap_bytes,
 pg_relation_filenode('compact_demo.items') AS file_id;
DELETE FROM compact_demo.items WHERE id<=4500;
VACUUM (ANALYZE) compact_demo.items;
SELECT pg_relation_size('compact_demo.items')=heap_bytes AS same_heap_size,
 pg_relation_filenode('compact_demo.items')=file_id AS same_file
FROM compact_demo.baseline;

两个比较都返回真：堆文件大小与文件标识没有改变。存活行位于原文件尾部，末尾不存在可以截断的连续空页，所以普通清理不能通过截断来缩小这个特定文件。这不代表普通清理永远不会缩文件；如果末尾确实存在可释放的空页，就可能归还相应空间。这里要区分样本布局和命令的一般能力。

甲读取剩下的五百行，并保持事务打开：

BEGIN;
SELECT count(*) FROM compact_demo.items;

甲没有执行任何更新，但仍持有对应表锁。乙给重写设置很短的取锁预算，避免实验无期限等待：

SELECT current_setting('lock_timeout') AS original_lock_timeout \gset
SET lock_timeout='100ms';
\set ON_ERROR_STOP off
VACUUM (FULL) compact_demo.items;
\set full_state :SQLSTATE
\set ON_ERROR_STOP on
SET lock_timeout = :'original_lock_timeout';
SELECT 1 / (:'full_state' = '55P03')::integer AS expected_lock_timeout;

必须立即保存 SQLSTATE，因为恢复超时设置也会执行查询，覆盖刚才的状态。只有 55P03 让整数分母等于一；意外成功或其他错误会触发除零，并在 ON_ERROR_STOP 下停止脚本。恢复乙原先保存的设置后，断言必须返回一。甲在下一步前仍保持事务打开；失败时须手动释放，不能因乙停止就假设甲也清理完毕。这个断言提案仍未在并发会话中执行；毫秒预算只是实验值，不是实际维护参数，也不能据此推算大表重写耗时。

甲现在结束读事务，释放它持有的锁：

COMMIT;

乙可以执行重写，再检查存储标识和所有保留字段：

VACUUM (FULL,ANALYZE) compact_demo.items;
SELECT pg_relation_size('compact_demo.items')<heap_bytes AS smaller_heap,
 pg_relation_filenode('compact_demo.items')<>file_id AS different_file
FROM compact_demo.baseline;
SELECT count(*),min(id),max(id),sum(id),
 bool_and(payload=repeat(md5(id::text),10)) AS payloads_preserved
FROM compact_demo.items;
DO $$ BEGIN
 IF (SELECT sum(id) FROM compact_demo.items)<>2375250
 OR (SELECT count(*) FROM compact_demo.items)<>500
 OR EXISTS (SELECT FROM compact_demo.items
 WHERE payload<>repeat(md5(id::text),10)) THEN
 RAISE EXCEPTION 'compaction changed application data';
 END IF;
END $$;
DROP SCHEMA compact_demo CASCADE;

两个存储比较都返回真：堆文件更小，文件标识也变了。数据检查应返回五百行，编号范围四千五百零一至五千，编号总和为二百三十七万五千二百五十，所有载荷匹配也为真。断言同时检查记录数量与内容，因为文件变小本身并不能证明压缩过程保留了正确的数据。成功时最后删除整个实验模式；较早的错误可能留下它，应先释放甲的事务，再检查可丢弃实验环境并清理。

判断重写是否值得

如果后续插入本来就会使用现有空闲空间，保留这些容量可能比先付出重写代价、之后再次扩展文件更合适。应在负载趋于稳定后，评估持续存在的额外空间和访问成本。还要区分主堆文件、索引和辅助存储，因为一个笼统的表大小数字，可能混合了几类增长原因不同的对象。选择维护动作之前，先确认真正占空间的是哪一部分。

安排维护时，应确认业务可以接受独占锁，并在请求强锁之前检查长时间打开的读事务。流量低并不保证没有旧事务留下。取锁等待应有明确预算，失败后先观察原因，而不是无限重试；完成后同时验证数据和存储变化。日常仍要保持普通回收健康，避免严重积压变成每次都需要独占重写的维护循环。

这个实验在小表上展示了锁冲突、文件替换和行内容保留，却不能预测生产对象的重写耗时与额外容量。大索引、外部存储值和复制日志流量都会改变代价，需要结合实际对象测量。只有把可承受的锁窗口、磁盘余量和验证方式都纳入维护安排，文件压缩才是完整的操作，而不是一条碰运气的命令。

来源

PostgreSQL 18 VACUUM，重写、额外空间、尾部截断与事务限制，已核验 2026-09-10。
PostgreSQL 18 显式锁，强排他表锁与读取、写入的冲突关系，已核验 2026-09-10。
PostgreSQL 18 常规清理，日常空间复用与例外性的完整压缩，已核验 2026-09-10。
PostgreSQL 18 psql，SQLSTATE 保存、变量插值与脚本错误处理，已核验 2026-10-19。
PostgreSQL 18 错误码，55P03 lock_not_available 的身份，已核验 2026-10-19。

Postgres 流式复制让备用节点保持温热

Tue, 10 Aug 2027 00:00:00 +0000

物理流复制把 PostgreSQL WAL 发送到备库，备库通过重放记录维持集群的另一份副本。发送不必等待整个日志段结束。这与选择部分表变更进行传送的逻辑复制不同。接收进程正在运行、备库可以连接，都是有价值的健康信号，但任何一个信号都不能单独证明某条已经提交的业务记录此刻在备库可见。

坏掉的样子

流复制默认是异步的。主库可以先向客户端确认提交，备库之后才收到或应用相关记录。若主库恰好在这个窗口丢失，切换到备库时可能丢掉最近已经确认的工作。备库也可能保持连接并持续接收日志，却由于暂停回放而一直返回旧行。因此网络交付在推进，并不能证明查询新鲜度也在推进。

应区分不同进度标记。备库的接收位置函数报告通过流复制已经接收并同步到磁盘的位置，回放位置函数则报告已经应用的位置，两者差值可以暴露回放积压。最后一次重放事务的时间戳，即使在完全空闲的系统上也会不断变旧；单纯用当前时间减去它，不能可靠判断究竟有多少尚未处理的工作。

接收、回放与提升是不同边界。条长仅定性示意；主备演练仍待运行验证。

快速验证

使用非超级操作系统账户，在 Linux 环境中准备 PostgreSQL 18 服务端与客户端程序。原文记录了 PostgreSQL 18.6 执行结果，本轮未重跑。它创建私有临时集群及 Unix 套接字目录，不打开 TCP 监听，但 Unix 套接字仍是监听端点，必须得到执行环境允许。本地信任认证仅用于这些可丢弃的实验实例。少量日志预留支持这个有界演练，脚本没有配置永久复制槽。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-streaming.XXXXXX)
mkdir "$lab/socket"
primary=$lab/primary
standby=$lab/standby
cleanup() {
 for cluster in "$standby" "$primary"; do
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
 done
}
trap cleanup EXIT
initdb -D "$primary" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$primary/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
wal_level = replica
max_wal_senders = 4
wal_keep_size = '64MB'
CONF
pg_ctl -D "$primary" -l "$lab/primary.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
CREATE TABLE marker (id integer PRIMARY KEY,value text);
INSERT INTO marker VALUES (1,'base');
SQL
pg_basebackup -D "$standby" -R -X stream -c fast -w
cat >> "$standby/postgresql.conf" <<CONF
port = 56433
hot_standby = on
CONF
pg_ctl -D "$standby" -l "$lab/standby.log" -w -t 15 start >/dev/null
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_wal_replay_pause()' >/dev/null
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_get_wal_replay_pause_state()='paused'")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || { echo 'replay did not pause' >&2; exit 1; }
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt -c "INSERT INTO marker VALUES (2,'later')"
target=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_current_wal_lsn()')
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_last_wal_receive_lsn()>='$target'::pg_lsn")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 150 || { echo 'receiver did not catch up' >&2; exit 1; }
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT state,sync_state FROM pg_stat_replication'
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<SQL
SELECT pg_last_wal_receive_lsn()>='$target'::pg_lsn,
 pg_last_wal_replay_lsn()<'$target'::pg_lsn,
 (SELECT count(*) FROM marker);
DO \$\$ BEGIN
 IF (pg_last_wal_receive_lsn()>='$target'::pg_lsn
 AND pg_last_wal_replay_lsn()<'$target'::pg_lsn
 AND (SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker)='1:base')
 IS NOT TRUE THEN
 RAISE EXCEPTION 'paused replay result mismatch';
 END IF;
END \$\$;
SQL
echo stale_read_while_receiving
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_wal_replay_resume()' >/dev/null
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_last_wal_replay_lsn()>='$target'::pg_lsn")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 150 || { echo 'replay did not catch up' >&2; exit 1; }
 sleep 0.1
done
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT id,value FROM marker ORDER BY id;
DO $$ BEGIN
 IF (SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker)
 IS DISTINCT FROM '1:base,2:later' THEN
 RAISE EXCEPTION 'resumed replay result mismatch';
 END IF;
END $$;
SQL
pg_ctl -D "$primary" -m fast -w stop >/dev/null
echo old_primary_stopped
pg_ctl -D "$standby" -w -t 15 promote >/dev/null
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT pg_is_in_recovery();
INSERT INTO marker VALUES (3,'promoted');
SELECT id,value FROM marker ORDER BY id;
DO $$ BEGIN
 IF pg_is_in_recovery() OR (SELECT count(*) FROM marker)<>3 THEN
 RAISE EXCEPTION 'promotion result mismatch';
 END IF;
END $$;
SQL
printf 'lab_directory %s\n' "$lab"

脚本通过带恢复配置选项的物理基础备份建立副本，这个选项会写入备库连接信息并创建备库信号文件。副本在另一个套接字端口启动后，先请求暂停回放，再等待状态确实变成已经暂停。随后主库提交第二行，并捕获提交之后的日志位置，作为接收与回放比较的明确目标。

主库的预期状态是正在流复制且采用异步确认。备库输出的两个真值与行数一，分别表示接收已经到达目标、回放仍未到达、表里只有原始一行。断言还会检查这一行的实际内容。因此“仍在接收时读到旧数据”的标记来自数据库真实查询结果，并不是在应用缓存中人为伪造一段延迟。

恢复回放之后，脚本等待回放位置达到目标，再核对第一行为 base、第二行为 later。每次观察都使用新连接，排除了先前打开的事务快照导致旧结果的干扰。真实应用中的长事务如果继续持有旧快照，即使备库已经回放到新位置，也可能还需要结束那个事务才能读到新版本；这是另一条需要单独识别的可见性边界。

接管步骤先停止旧主库，再提升备库并等待提升完成。恢复状态变为假，第三行写入后得到 promoted，断言验证新主库确实接受了这次写入。所有实验服务都会在退出时停止，打印目录保留日志。这验证的是隔离环境里的有序提升，没有验证自动故障探测、网络分区处理或客户端地址迁移，不能据此宣称整套高可用切换已经完成。

明确确认与保留契约

同步复制既需要选择同步备库，也需要相关事务同步提交设置。仅把事务选项设为开启，而没有选择任何同步备库，不会凭空增加远端确认要求。配置好同步备库之后，普通开启模式等待它们持久化日志；远端写入模式等待写入对方操作系统；远端应用模式等待对方重放。这些选择改变的不只是持久性与读取可见性，也包括提交延迟以及备库不可用时的服务可用性。远端应用确认只覆盖参与确认的备库，不覆盖负载均衡器后面的所有副本；随后把读取送到别处，仍可能返回旧数据。

日志保留是另一项独立义务。复制槽可以保留断线接收者仍需要的日志，但消费者长期停滞时，若没有有意识地设置限制与监控，也可能耗尽磁盘。没有足够保留日志或可用归档时，过旧的备库可能只能重建。应联合观察日志生成、接收、回放、保留字节数与剩余空间，不要只看某一个复制进程是否还活着。

提升本身不会隔离另一个仍然写入的主库。生产故障切换必须阻止旧写入者继续服务，选择可接受的恢复位置，重定向客户端，并通过受支持的重建或回绕流程让原主库重新加入。否则两个独立写入者可能产生分叉。一个健康的流复制连接只证明其中一部分机制正在工作，不能替代完整接管流程及其业务数据核验。

来源

PostgreSQL 18 温备与流复制，异步交付、同步确认、日志保留与故障切换，已核验 2026-10-15。
PostgreSQL 18 管理函数，接收和回放位置、实际暂停状态及提升语义，已核验 2026-10-15。
PostgreSQL 18 pg_basebackup，使用恢复配置选项创建备库，已核验 2026-10-15。

Postgres 连接很贵，要复用与池化

Mon, 09 Aug 2027 00:00:00 +0000

温热的连接池能够减少反复建立 PostgreSQL 连接，但空闲连接在池里等待期间也可能消失。服务器结束会话、网络故障或中间设备的空闲策略，都可能让客户端仍握着一个已经不能使用的套接字。复用方案必须包含失效识别和替换；对象还在池里，只说明应用保存了它，不能证明下一条查询一定成功。

坏掉的样子

TCP 保活能够识别原本空闲连接上的部分故障，却不会替 SQL 设置执行截止时间，也不证明数据库能够完成某个具体请求，更不会处理结果未知的提交。客户端连接参数只作用于 TCP，使用 Unix 域套接字时相关选项会被忽略；服务器端保活设置控制的是另一端。具体操作系统是否支持某个选项，也会影响最终行为，不能只看参数字符串存在就宣称故障检测已经发生。

借出前健康检查，可以在把连接交给调用方之前识别已经失效的连接。Psycopg 默认不执行这种检查，但提供回调让应用选择启用。多一次探测意味着额外往返，也仍然无法阻止连接在探测成功后立刻出故障。因此，建立连接、等待租用和执行语句，都需要各自的预算与错误处理，不能用一个“保活开启”覆盖全部阶段。

显式终止后端与语句取消验证不同失败。libpq 参数字符串不测量内核保活计时；TCP 运行仍待验证。

快速验证

准备 Python 3.10 或更新版本，通过 TCP 连接使用默认零值语句超时的 PostgreSQL 18，并安装原演练使用的版本：python3 -m pip install "psycopg[binary]==3.3.5" "psycopg-pool==3.3.1"。把 PG_DSN 设置为可丢弃数据库，使用允许结束自己后台连接的角色。保存为 liveness-demo.py 后运行。程序先记录每个测试池刚创建的连接标识，然后只结束那条已经归还、处于空闲状态的连接：

import os

import psycopg
from psycopg.errors import QueryCanceled
from psycopg_pool import ConnectionPool

dsn = os.environ['PG_DSN']
with psycopg.connect(dsn, autocommit=True) as admin:
 for checked in (False, True):
 with ConnectionPool(
 dsn, min_size=1, max_size=1, timeout=3, open=True,
 check=ConnectionPool.check_connection if checked else None,
 kwargs={
 'connect_timeout': 2,
 'keepalives': 1,
 'keepalives_idle': 30,
 'keepalives_interval': 10,
 'keepalives_count': 3,
 },
 ) as pool:
 pool.wait(timeout=3)
 with pool.connection() as conn:
 assert conn.execute('SELECT inet_server_addr() IS NOT NULL').fetchone()[0]
 original_pid = conn.info.backend_pid
 parameters = conn.info.get_parameters()
 assert [parameters[k] for k in (
 'keepalives', 'keepalives_idle', 'keepalives_interval', 'keepalives_count'
 )] == ['1', '30', '10', '3']
 # Terminate only the idle connection just created by this fixture.
 assert admin.execute('SELECT pg_terminate_backend(%s,2000)', (original_pid,)).fetchone()[0]

 if not checked:
 try:
 with pool.connection() as conn:
 conn.execute('SELECT 1')
 except psycopg.OperationalError as error:
 print('unchecked_first_use', error.sqlstate)
 else:
 raise AssertionError('terminated connection unexpectedly worked')

 with pool.connection() as conn:
 replacement_pid = conn.info.backend_pid
 assert replacement_pid != original_pid
 assert conn.execute('SELECT 1').fetchone()[0] == 1
 print('checked', checked, 'replacement', True)

 try:
 with pool.connection() as conn:
 conn.execute("SET LOCAL statement_timeout='50ms'")
 conn.execute('SELECT pg_sleep(0.2)')
 except QueryCanceled as error:
 assert error.sqlstate == '57014'
 print('statement_timeout', error.sqlstate)
 else:
 raise AssertionError('long statement did not time out')

 with pool.connection() as conn:
 assert conn.info.backend_pid == replacement_pid
 assert conn.execute('SHOW statement_timeout').fetchone()[0] == '0'
 assert conn.execute('SELECT 1').fetchone()[0] == 1
 print('healthy_after_rollback', True)

两种情况都配置客户端保活，并检查 libpq 报告的连接参数，不打印整个连接串。这没有测量内核探测时序，也不证明所有平台都支持每个选项。第一种没有借出前检查。空闲后端被服务器结束后，下次读取遭遇操作错误；本次这种明确的服务器关闭返回 57P01。池随后丢弃坏连接，下一次借用得到不同的后端标识，并成功返回一。

第二种启用内置的连接检查回调。经过同样的受控终止，获取阶段发现旧连接不能使用，再把正常的新连接交给借用者。两种情况最后都报告完成替换，但只有未检查的那一种，把首次使用旧连接的错误直接暴露给业务代码。原实验验证的是显式服务器终止，不是静默网络分区，也没有等待 TCP 保活探测计时器真正触发。本轮审阅未重新执行 TCP 实验。

每种情况还会在五十毫秒的事务局部语句预算下，执行二百毫秒睡眠，预期得到 57014。此时连接仍然活着，TCP 保活也已启用，查询却依旧需要自己的截止时间。异常离开连接上下文后，失败事务被回滚；后续借用继续使用同一个替代后端，看到语句超时恢复为原来的零，并能正常读取一。

这些检查区分了两件事：死连接需要替换，活连接上的语句取消则可以通过正确事务清理恢复。实验还确认局部超时设置没有泄漏给下一位借用者。不能把所有 SQL 错误都当成必须销毁连接的证据，也不能因为健康探测成功，就删除执行阶段的预算。判断应跟随错误发生的阶段，以及对应连接和事务的真实状态。

在明确的操作边界重新连接

池的最大空闲时间和最大寿命，有助于管理连接轮换，但都不能保证套接字一定活到设置的年龄。在 Psycopg 中，max_idle 只回收超过 min_size 的闲置连接，不会把最低预热数量中的每条空闲连接都定时关闭。服务器或中间设备可能更早关闭连接。应协调这些策略，观察丢弃、重连次数和故障期间的获取延迟；健康检查过于频繁，也会给大量短查询增加不可忽略的往返成本。策略需要结合请求长度和故障特征，而不是越积极越可靠。

示例是在应用写入开始之前替换空闲连接。提交期间断连则不同：数据库可能已经提交，只是确认丢失。建立新连接不会自动告诉调用方上一笔究竟成功没有，直接重放写入就可能重复副作用。应保留稳定操作标识，并查询持久化结果，在结果得到核实后再决定是否重发非幂等工作。

获取连接的多次尝试，还应受调用方取消和请求总截止时间控制，避免请求已经结束，后台重连仍然不停消耗资源。保活、健康检查、获取预算和语句预算可以共同工作，但每一项都只回答自己的问题；把它们对应到具体操作边界，才能知道错误之后应该替换连接、回滚事务，还是先核对已经提交的结果。

来源

PostgreSQL 18 libpq 连接参数，客户端保活、套接字适用范围与连接选项，已核验 2026-10-15。
Psycopg 连接池文档源码，借出前检查与失效连接替换，已核验 2026-10-15。
Psycopg 连接池 API 文档源码，可选检查回调与连接生命周期控制，已核验 2026-10-15。
PostgreSQL 18 客户端连接默认值，语句超时与连接存活的不同边界，已核验 2026-10-15。

Postgres 序列用一个缓存发号

Mon, 02 Aug 2027 00:00:00 +0000

PostgreSQL 序列缓存为数据库后端预留数值，不属于某个应用对象，也不只属于一笔事务。理解这个边界，才能解释为什么序列保存的位置会领先于真正返回的号码，为什么重新连接也会留下空洞，以及为什么调小 CACHE 不能让标识连续。首先要区分分配器状态，与应用真正成功提交的业务记录，不能把两者当成同一个计数器。

三个不同的数字

一个新建的升序序列使用 CACHE 5 时，第一次 nextval 可以返回一，而 last_value 已记录五。后者是预留边界，不是已插入行数，也不表示一到五都已经交给应用。currval 表示当前会话最近为该序列建立的值，其他连接取号不会替换它。监控时若不说明这些字段的作用域，就很容易把预留数量误当成业务数量。

同一后端后续取号，可以使用已经预留的数值。PostgreSQL 实现中既有后端局部的快速路径，也有补充缓存时的缓冲锁；把每次 nextval 都说成对普通表记录加一把行锁并不准确。缓存减少反复访问序列状态，但不能据此认定某个应用的插入延迟主要来自序列竞争。修改参数前，应先测量真实瓶颈，而不是根据取号机制猜测整体性能。

会话寿命也影响空号

即使正常退出，会话结束时没有用完的预留值也会被放弃。因此，相同取号速率下，频繁建立数据库会话的服务，可能比使用长期连接池的服务放弃更多预留。缓存跟随服务器会话；应用看到一个连接对象，并不足以说明底层数据库会话是否一直存在，连接复用策略也是实验条件的一部分。

不同会话还可以分别持有不同区间。一个先返回一，另一个返回六，第一个随后再返回二。这是分配交错，不代表提交顺序，也不能证明这些值已经丢失。即使 CACHE 为一，事务仍可能先取号后提交，顺序与另一个事务相反。提交之前写入的时间戳同样不能自动提供真实提交顺序，不能只给字段换个名字就获得新的保证。

坏掉的样子

不要把 CACHE 当成崩溃后最大跳号数的公式。多个会话可以同时持有预留，而实现还会把一部分未来序列进度提前写入日志。事务回滚、走冲突处理分支的插入，以及取到但没有使用的值，都会增加空洞。缺号本身既不能证明丢了业务数据，也不能证明没有丢；发现故障时，应核对已提交记录和恢复证据，再判断是否只是分配器行为。

正常运行期间，非循环分配在管理员没有把序列重置回已用范围时，会提供不同数值。但循环、手工重置，以及显式导入编号，都可能改变这个前提。表仍然需要主键或唯一约束保证存储完整性。减小缓存不能代替这些约束，不能找回已经删除的记录，也不会自动让业务编号流程具备可审计性。在数据库外持久使用一个号码之前，应先提交取号事务；崩溃可能使尚未提交的序列变化是否保留变得不确定。

调整序列设置时，还要考虑活跃会话已经拿到的预留值。不要为了补洞，在并发写入期间把序列随意重置到表中最大编号。如果业务确实要求已签发号码连续，应先明确签发、回滚、取消和外部发布的边界，再评估事务计数器。没有经过实际负载测量，就不存在可以普遍承诺的最佳缓存大小或吞吐提升倍数。

已返回的二与从未返回的四、五是不同空号来源。历史原样脚本仅覆盖先后单用户后端，不证明崩溃跳号或并发。

快速验证

下面的无套接字练习，使用两个先后运行的单用户后端，访问同一个新初始化的可丢弃集群。以非 root 账户执行脚本，并把 PostgreSQL 18 的 initdb 与 postgres 放入 PATH。绝不能让单用户模式访问正在运行的集群。该模式具有隐式超级用户权限，不能验证并发客户端、真实进程间锁竞争或故障切换；本例只研究缓存预留的生命周期。

#!/bin/sh
set -eu
umask 077
export LC_ALL=C
lab=$(mktemp -d "${TMPDIR:-/tmp}/xbcatm-sequence-cache.XXXXXX")
initdb -D "$lab/data" --no-locale --encoding=UTF8 \
 --auth-local=trust --auth-host=reject >"$lab/init.log" 2>&1
postgres --single -j -D "$lab/data" -c io_method=sync -c log_min_messages=notice postgres \
 >"$lab/session-a.log" 2>&1 <<'SQL'
CREATE SEQUENCE cache_probe CACHE 5;

SELECT nextval('cache_probe') AS first_value;

SELECT last_value AS reserved_through FROM cache_probe;

BEGIN;

SELECT nextval('cache_probe') AS rolled_back_value;

ROLLBACK;

SELECT nextval('cache_probe') AS after_rollback;

DO $$ BEGIN
 IF currval('cache_probe') <> 3 OR
 (SELECT last_value FROM cache_probe) <> 5 THEN
 RAISE EXCEPTION 'cache reservation or rollback result wrong';
 END IF;
 RAISE NOTICE 'cache_probe_a_ok';
END $$;

SQL
if grep -E '(ERROR|FATAL|PANIC):' "$lab/session-a.log"; then exit 1; fi
grep -q 'cache_probe_a_ok' "$lab/session-a.log"
postgres --single -j -D "$lab/data" -c io_method=sync -c log_min_messages=notice postgres \
 >"$lab/session-b.log" 2>&1 <<'SQL'
SELECT nextval('cache_probe') AS after_clean_session_end;

DO $$ BEGIN
 IF currval('cache_probe') <> 6 OR
 (SELECT last_value FROM cache_probe) <> 10 THEN
 RAISE EXCEPTION 'unused cache values were unexpectedly reused';
 END IF;
 RAISE NOTICE 'cache_probe_b_ok';
END $$;

DROP SEQUENCE cache_probe;

SQL
if grep -E '(ERROR|FATAL|PANIC):' "$lab/session-b.log"; then exit 1; fi
grep -q 'cache_probe_b_ok' "$lab/session-b.log"
cat "$lab/session-a.log" "$lab/session-b.log"
printf 'retained_lab %s\n' "$lab"

保留的原样完整脚本记录与原始日志报告 PostgreSQL 18.6 执行通过；本轮源文审阅没有重跑脚本。第一个后端返回一，记录预留边界五，在随后回滚的事务中分配二，再返回三。断言核对缓存边界仍为五。单用户模式的 -j 使用空行划分命令，因此脚本保留必要的空行，确保事务边界没有因整段输入被视为同一条命令而改变。观察结果时，也需要区分真正执行的语句与后端输出的提示文字。

第一个后端正常结束后，第二个返回六，并记录预留边界十。四和五从未返回给调用方，二则已经返回，但属于最后回滚的事务。这是在没有制造崩溃的情况下，演示两种不同空洞来源。两个成功通知都出现，序列最终被删除；脚本打印的目录保留可丢弃集群与日志，以便检查完整输出；这不是自动文件系统清理，失败也可能留下这些文件。

脚本同时检查错误文本和进程状态，因为独立后端即使报告 SQL 错误，也可能以成功状态结束。这个练习验证预留与会话结束的关系，不是吞吐基准或持久性演练。它不能提供固定崩溃跳号上限，也不能据此推荐生产缓存大小。迁移结论时，必须保持实验覆盖范围与实际业务问题一致。

来源

PostgreSQL CREATE SEQUENCE，会话预留、顺序和未使用数值，已核验 2026-10-15。
PostgreSQL 序列函数，回滚、会话值与完整性边界，已核验 2026-10-15。
PostgreSQL 18 序列实现，后端局部分配与预写日志，已核验 2026-10-15。
PostgreSQL 独立服务进程，单用户命令边界与限制，已核验 2026-10-15。

Postgres JSONB 搭配 GIN 做灵活查询

Wed, 28 Jul 2027 00:00:00 +0000

PostgreSQL 的 JSONB 列可以容纳形态不同的文档，但高效查询仍要求条件与索引有准确的对应关系。对整篇文档建立 GIN 索引，只能支持特定的 JSONB 算子，不能自动加速所有从文档提取字段的表达式。先确定数据类型和查询语义，再选择索引，才能避免建完索引却没有收益。

让算子与索引对应

包含条件 payload @> '{"status":"pending"}' 检查文档是否包含该键及对应的 JSON 字符串值。采用默认 jsonb_ops 操作符类时，整列 GIN 可以支持包含、顶层键存在判断，以及能够提取索引条件的 JSON 路径查询。索引保存可检索的组成部分；位图堆扫描仍可能访问表，并重新检查候选行，不能把它理解为完全不用回表。

payload->>'status' = 'pending' 则是在比较提取后的文本。payload 上的 GIN 并不是这个文本表达式的索引。对 (payload->>'status') 建立 B-tree 表达式索引，才与标量等值查询对应。如果很多查询需要对 status 排序、关联或施加约束，独立的有类型列可能更清楚，也能减少不断从灵活文档中推导字段的成本。

不能未经类型检查，就把所有文本条件改写成包含条件。JSON 数字和 JSON 字符串经过文本提取后可能得到相同文本，但包含算子会区分它们的 JSON 类型。只有数据约束保证相关前提时，改写才等价。应用应通过数据库驱动绑定参数，而不是把不可信输入拼接进 SQL 或 JSON 字符串；索引选择和输入处理需要分别正确。

操作符类也决定能力边界。jsonb_path_ops 支持包含以及适用的路径匹配，但不支持 jsonb_ops 提供的键存在算子。对合适数据，它可能更小、选择性更好，却不是无条件更优的替代品。同样，嵌套表达式索引必须对应实际使用的表达式，给完整文档建索引，并不意味着提取后的每棵子树都自动有独立索引。

缺失和空值是不同问题

键不存在、键对应 JSON null、键对应字符串“null”，是三种状态。存在判断会把后两种都视为存在。用 -> 提取 JSON 时，缺失键得到 SQL NULL，显式 null 得到 JSON null 值。用 ->> 提取文本时，缺失与 JSON null 都变成 SQL NULL，而字符串仍保留为文本。这些差别会影响过滤、唯一性假设和应用默认值。

如果业务关心键是否出现，应使用键存在检查；如果字段必须是字符串或数字，还要检查 JSON 类型。用普通等号和 NULL 比较，不能表达“键不存在”。另外，? 只检查顶层，不会递归查找文档任意深度的同名键。查询内部对象时，必须明确路径及对应索引，不能因某处存在同名键就认为顶层条件成立。

坏掉的样子

常见性能问题是建了 GIN，却保留不兼容的文本提取条件。另一个错误是认为索引只要适用，就一定会被选择。统计信息、选择性、表大小和成本估计都会影响计划；读取大部分数据时，顺序扫描可能合理。应先比较估计行数与实际行数，再判断问题是估计偏差、条件不匹配，还是索引本身收益不足。

大型灵活文档也会增加写入工作。GIN 要维护许多条目，更新文档依然是更新一行，会付出相应的锁和存储成本。应围绕真实负载的问题建立索引，不要为假想查询覆盖整篇文档。JSONB 语法合法，也不能证明必要业务字段存在或类型正确；这些要求要由实际契约和校验承担。新增 CHECK 时还要记住，表达式结果为 SQL NULL 也会通过检查；应明确要求键存在及类型正确，不能仅依赖可能返回空值的文本提取条件。

包含查询有历史执行；标量提取只有规划。相同文本不足以证明类型化包含等价。

快速验证

把下面内容保存为 json-query.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f json-query.sql。实验在事务中创建临时数据，末尾回滚清除。保留默认的无限制设置 gin_fuzzy_search_limit=0。其中只有百分之一的行处于 pending 状态，便于观察选择性较高时的计划。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE documents (id integer, payload jsonb NOT NULL);
INSERT INTO documents SELECT g, jsonb_build_object('status',
 CASE WHEN g%100=0 THEN 'pending' ELSE 'done' END)
FROM generate_series(1,10000) AS g;
CREATE INDEX documents_payload ON documents USING gin(payload);
ANALYZE documents;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id FROM documents WHERE payload @> '{"status":"pending"}';
EXPLAIN (COSTS OFF)
SELECT id FROM documents WHERE payload->>'status'='pending';
CREATE INDEX documents_status ON documents ((payload->>'status'));
ANALYZE documents;
EXPLAIN (COSTS OFF)
SELECT id FROM documents WHERE payload->>'status'='pending';
SELECT value, value ? 'x' AS has_key,
 value->'x' IS NULL AS sql_null_json, value->>'x' IS NULL AS sql_null_text
FROM (VALUES ('{}'::jsonb),('{"x":null}'::jsonb),('{"x":"null"}'::jsonb)) v(value);
DO $$ BEGIN
 IF (SELECT count(*) FROM documents WHERE payload @> '{"status":"pending"}') <> 100 THEN
 RAISE EXCEPTION 'wrong containment count';
 END IF;
 IF '{"n":1}'::jsonb @> '{"n":"1"}'::jsonb THEN
 RAISE EXCEPTION 'number and string were conflated';
 END IF;
 IF '{"outer":{"x":1}}'::jsonb ? 'x' THEN
 RAISE EXCEPTION 'top-level existence searched recursively';
 END IF;
 IF ('{"x":null}'::jsonb->'x') IS NULL THEN
 RAISE EXCEPTION 'JSON null confused with missing key';
 END IF;
END $$;
ROLLBACK;

保留的 PostgreSQL 18.6 单用户 SQL 日志显示，包含查询通过 documents_payload 使用位图索引扫描并返回一百行。本轮源文审阅没有重跑，早先也未执行 psql 指令与客户端调用。不带 ANALYZE 的 EXPLAIN 先把文本条件规划为顺序扫描，再规划为使用 documents_status；这两次调用没有执行文本查询，也没有比较它与包含查询返回的标识。这些只是该分布下的计划观测，不是固定计划或生产延迟承诺；更换规模或形态后仍应复核。

最后三行分别展示缺失、显式 JSON null 和文本字符串。它们的存在标记依次为假、真、真；文本提取结果是否为 SQL NULL 的标记依次为真、真、假。断言还验证包含判断区分类型，键存在检查不会递归。修改查询形态时，应保留这些语义检查：只有结果仍符合预期，计划变快才有价值，不能用一个更快但混淆空值或类型的条件替代原有业务含义。

来源

PostgreSQL JSON 类型与索引，GIN 操作符类与表达式索引，已核验 2026-10-15。
PostgreSQL JSON 函数与操作符，提取、存在、包含和空值语义，已核验 2026-10-15。
PostgreSQL 18: CHECK 约束的空值行为，CHECK 接受未知结果及显式空值约束，已核验 2026-10-15。

Postgres 索引的存在意义就是回答问题

Tue, 20 Jul 2027 00:00:00 +0000

索引的价值在于改变真实查询需要完成的工作，索引了多少列并不是有效的成功指标。一个能直接找到某位客户最新三笔订单的窄 B-tree，可能胜过无法提供所需顺序的宽索引；读取几乎全部行的查询，则可能正确地忽略两者。评估时要把访问方式、排序和返回数据量放在一起，而不是看到索引名称就宣布优化完成。

从需要的结果出发

假设应用要查询某位客户最新三笔订单。customer 的等值条件缩小候选范围，placed_at 降序选择该客户最新记录，再用 id 作为最后决胜键，处理时间戳相同的情况。(customer, placed_at DESC, id DESC) 就表达了这条查询需要的键顺序。每个键都应对应可解释的条件或排序要求，而不是根据列名凭直觉添加。

收益不只是避免全表扫描。有序索引路径可以取得所需的有限结果后就停止，不必先收集该客户全部订单再排序。去掉 LIMIT，或改成返回大部分行后，成本平衡可能变化。因此同一个索引必须结合完整 SQL 和常用参数评价，不能只盯 WHERE 的一个片段，更不能把少量结果的计划当成大规模导出的保证。

WHERE 条件的文本顺序不会定义索引顺序。PostgreSQL 规划逻辑表达式，把 customer 等值写在 AND 前面或后面，不会重排 B-tree。真正相关的是索引方向、空值顺序、前导键限制和最终 ORDER BY。修改查询时应明确核对这些结构属性，而不是套用“列写在前面就能用索引”的笼统规则。PostgreSQL 18 还能在缺失前导键的不同值较少时，对某些后续键条件采用 B-tree skip scan；没有前导等值条件，并非绝对禁止使用索引。

如实读取执行计划

EXPLAIN 展示计划工作，EXPLAIN ANALYZE 会真正执行并报告实际行数和循环次数。查询返回表中大部分数据，尤其需要索引中没有的宽列时，顺序扫描可能是正确选择。这不证明列顺序错误，也不证明索引创建失败。应把它看成优化器在当前条件下选择的访问成本，而不是必须消除的红色标记。

反过来，出现索引名也不证明查询便宜。索引扫描仍可能访问大量条目和堆元组，bitmap 路径可能还要排序，index-only 计划也可能检查堆可见性。结合 actual rows、适用时的 Heap Fetches、缓冲区活动和 Sort 阅读。顶层有 LIMIT 只有在下层也避免了大量多余工作时才真正省事，不能忽略 LIMIT 下面的完整树。

坏掉的样子

生产参数可能比开发参数多选出几千倍的行。小客户上表现优秀的索引，对拥有大量订单的大客户未必同样合算。数据分布、统计信息、缓存和并发都会影响计划与延迟，验证变更时应保留多个代表性参数。只测试一个常见编号，很容易遗漏真正拖慢系统的极端但合法客户。

索引还会持续产生存储、缓存、写入维护和构建成本。仅因为一次诊断查询返回 note，就把宽 note 加入热索引，可能让日常写入更贵。应该区分窄的高频应用查找和偶尔的大范围报表，要求每个附加键或 INCLUDE 列都有反复出现的真实用途。不能用读路径的一次局部收益掩盖整个系统长期承担的维护工作。

还有一种问题是分页依赖未定义的顺序。时间戳相同或执行计划改变时，如果 ORDER BY 没有给出确定选择，前几条记录可能变化。索引本身不会独立建立 API 的排序契约。顺序应明确写在 SQL 中，测试也应检查具体标识，而不只是检查“返回了三行”，否则拿错三行仍可能通过表面的数量校验。

有序键与 LIMIT 服务窄查询；历史 index-only 执行仍访问堆，断言核对编号而非计划形态。

快速验证

保存为 topn.sql，运行 psql -X -v ON_ERROR_STOP=1 -f topn.sql，连接可丢弃的 PostgreSQL 18 数据库。夹具创建两万笔订单，分布在一百位客户中，并加入一个较宽的 note 列用于比较全量查询。表和索引都是临时对象，最后回滚清理，不依赖业务数据。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE orders (id integer, customer integer, placed_at integer, note text);
INSERT INTO orders SELECT g, g%100, g, repeat('x',100) FROM generate_series(1,20000) AS g;
CREATE INDEX orders_customer_recent ON orders (customer, placed_at DESC, id DESC);
ANALYZE orders;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id,placed_at FROM orders WHERE customer=7 ORDER BY placed_at DESC,id DESC LIMIT 3;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT * FROM orders WHERE customer>=0;
SELECT array_agg(id ORDER BY placed_at DESC,id DESC) AS newest
FROM (SELECT id,placed_at FROM orders WHERE customer=7
 ORDER BY placed_at DESC,id DESC LIMIT 3) s;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY placed_at DESC,id DESC)
 FROM (SELECT id,placed_at FROM orders WHERE customer=7
 ORDER BY placed_at DESC,id DESC LIMIT 3) s)
 IS DISTINCT FROM ARRAY[19907,19807,19707] THEN
 RAISE EXCEPTION 'wrong newest orders';
 END IF;
END $$;
ROLLBACK;

客户七的结果按顺序是 19907,19807,19707。保留的 PostgreSQL 18.6 单用户 SQL 日志显示 Limit 加 index-only scan，找到三条匹配行后停止，并发生三次堆可见性访问。本轮源文审阅没有重跑，早先也未执行 psql 指令与客户端调用。查询所有客户并返回 note 时，计划选择顺序扫描，实际返回两万行。两种选择分别对应各自的任务，并不互相矛盾，也不说明某个索引突然失效。

断言检查确定的前三条结果，耗时和缓冲区数字不被写成固定预期。这个实验展示按工作负载使用索引，不提供跨机器速度倍数，也不保证生产数据与需求变化后同一计划永远最优。若未来增加全局排序、额外过滤或更多返回列，就应重新检查完整语句的访问路径和成本。

来源

PostgreSQL 多列索引，键条件与扫描范围，已核验 2026-10-15。
PostgreSQL 索引与 ORDER BY，有序读取与 LIMIT，已核验 2026-10-15。
PostgreSQL 使用 EXPLAIN，理解计划中的实际工作，已核验 2026-10-15。

Postgres · XB 现场笔记

事务拿锁时别的请求会礼貌等待

坏掉的样子

快速验证

恢复时不要扩大竞争

来源

部分索引的写入成本

区分成员资格与更新成本

可以使用与值得使用是两回事

坏掉的样子

快速验证

来源

延伸阅读

分区裁剪跳过查询不可能用到的整张分区

证明哪些分区不可能命中

参数也能在执行时触发裁剪

坏掉的样子

快速验证

来源

表分区按范围或键拆分数据

使用相邻的左闭右开范围

缺失范围是一种运维状态

坏掉的样子

快速验证

来源

窗口函数在不合并组的前提下排名

三个问题对应三种排名

明确分区与过滤时机

坏掉的样子

快速验证

来源

自动清理资格不等于执行完成

坏掉的样子

快速验证

找到真正限制清理的阶段

来源

代理键把身份与含义分开

生成身份与约束唯一性

单独保留业务唯一规则

坏掉的样子

快速验证

来源

查询变慢时同时检查计划与等待

保留可比较的基线

坏掉的样子

快速验证

顺着观察到的原因继续

来源

PostgreSQL 使用两层数据缓存

坏掉的样子

快速验证

为整个服务器分配内存

来源

哈希索引复核碰撞，也要维护变化的键

桶里究竟保存什么

坏掉的样子

快速验证

把维护也放进性能评估

来源

LATERAL 让每一行都有自己的子查询窗口

把关联条件写清楚

决定没有匹配时保留什么

坏掉的样子

快速验证

来源

pg_dump 拍一张一致的快照

理解快照覆盖什么

计算负载和依赖

坏掉的样子

快速验证

来源

PostgreSQL 时间函数取样于不同的时点

一个事务只有一个开始时刻

语句标记与实时读数

坏掉的样子

快速验证

来源

checkpoint 把脏缓冲刷到磁盘

坏掉的样子

快速验证