并发 · XB 现场笔记

建议锁寿命属于连接或事务

Wed, 24 Nov 2027 00:00:00 +0000

建议锁让应用使用一个标识来协调工作，不要求这个标识对应数据库里某一行。比如，多名工作者可以约定，同一时间只能有一个连接刷新某份报表。PostgreSQL 负责管理锁的持有与竞争，应用则负责定义标识的业务含义，以及哪些操作必须先拿锁才能执行。这个分工决定了它能提供的保障，也决定了绕过协议时会发生什么。

坏掉的样子

建议锁的键只能是一个大整数，或者两个普通整数，没有接受文本名字的函数重载。这两种键空间彼此独立。如果应用通过哈希把名称映射为数字，必须明确一致的编码规则，也要考虑碰撞；同一资源被不同算法映射到不同数字，同样会破坏协调。直接维护有文档的整数命名空间，通常比隐藏在各个调用方里的临时哈希规则更容易核对。

建议锁是参与者共同遵守的协议。忽略它的连接，仍然可以更新所谓受保护的表行；它不能代替唯一约束、事务或权限检查。会话锁在回滚后仍然保留，直到对应次数的解锁完成，或服务器结束该会话。事务锁则随事务结束释放。如果处于自动提交模式，一条语句取得的事务锁，在后续语句开始之前就已经释放，无法保护接下来才执行的工作。

快速验证

本轮没有重跑原样保留的双会话示例：单用户后端不能复现会话间竞争。以下结果保留为预期，不是新的并发验证。

准备同一个 PostgreSQL 18 可丢弃数据库，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。为本实验预留下面的整数键，不要与已有业务约定混用。按照块的顺序切换终端。甲先创建计数器：

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

甲传入显式文本类型的键，预期返回 42883，即不存在匹配的函数。故意报错这一段结束后恢复遇错停止设置：

\set ON_ERROR_STOP off
SELECT pg_advisory_lock('job-name'::text);
\echo text_key_state :SQLSTATE
\set ON_ERROR_STOP on

甲在事务里把同一把会话锁取两次，然后回滚。注意函数名使用的是会话级形式：

BEGIN;
SELECT pg_advisory_lock(8610,2);
SELECT pg_advisory_lock(8610,2);
ROLLBACK;

乙尝试非阻塞取锁，接着故意不遵守建议锁协议，直接更新计数器：

SELECT pg_try_advisory_lock(8610,2);
UPDATE advisory_demo.counter SET n=n+1 WHERE id=1 RETURNING n;

取锁返回假，更新却返回一。两个结果分别证明：甲的回滚没有释放会话锁；建议锁也没有自动阻挡普通表写入。甲现在解锁一次：

SELECT pg_advisory_unlock(8610,2);

虽然解锁返回真，乙仍然无法获得同一把锁：

SELECT pg_try_advisory_lock(8610,2);

甲还需要解除第二次获取：

SELECT pg_advisory_unlock(8610,2);

这时乙能够成功取锁，并明确释放自己刚获得的那一次持有：

SELECT pg_try_advisory_lock(8610,2);
SELECT pg_advisory_unlock(8610,2);

两个调用都返回真。同一会话重复成功取锁会累加持有次数，所以一次解锁成功，并不能证明该会话已经完全放弃资源。下一步，甲对另一个键使用事务级函数，并保持显式事务打开：

BEGIN;
SELECT pg_advisory_xact_lock(8610,3);

乙的非阻塞事务锁请求返回假，说明甲仍拥有该键：

SELECT pg_try_advisory_xact_lock(8610,3);

甲回滚，结束事务级持有：

ROLLBACK;

乙在自动提交模式下重新申请，这次返回真：

SELECT pg_try_advisory_xact_lock(8610,3);

紧接着，甲也在自动提交模式下申请相同的事务锁，仍返回真：

SELECT pg_try_advisory_xact_lock(8610,3);

两个真是先后成功，不是同时拥有同一把互斥锁。每条语句的隐式事务结束时，就已释放当次锁。此刻双方都不能认为自己还保护着未来的临界区。最后由甲核对计数值仍是一，并删除实验模式：

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

非阻塞取锁失败不会增加需要释放的持有次数。只有成功获取，才会成为当前会话或事务实际拥有的锁。

让持有寿命覆盖完整操作

如果被保护的数据库工作可以放在一个事务中，应显式开启事务、获取事务锁，再完成读取、判断和写入，最后结束事务。非阻塞取锁返回假时，意味着调用方没有取得所有权；此时应跳过或重新安排任务，不能无视返回值继续执行受保护工作。阻塞版本可能等待，因此取锁预算和重试策略也必须纳入这个业务操作的总时限。

只有确实需要跨越多次事务的持有周期时，才选择会话锁，而且获取、工作和释放必须使用同一条物理数据库连接。如果持锁后把连接还给池，后台会话可能继续持锁，却开始服务不相关的请求。事务池化尤其不能支持“下次请求仍回到原来那个持锁会话”的假设。这里要核对真实连接寿命，而不是仅看应用对象是否还是同一个名字。

服务器结束会话时会自动清理会话锁，不存在会话已经终止但锁永久残留的正常语义。不过，网络连接丢失的检测可能有延迟，不能假定客户端消失后其他工作者立即获得锁。锁也不记录任务是否已经完成。后续工作者取得所有权后，仍应检查已提交状态，判断是否需要执行，以及重复执行是否符合任务语义，不能把“我现在拿到了锁”误当成“此前无人完成过”。

来源

PostgreSQL 18 建议锁函数，允许的键类型及阻塞、非阻塞接口，已核验 2026-10-15。
PostgreSQL 18 显式锁，建议锁持有、重复获取和事务语义，已核验 2026-10-15。

事务让提交是原子的

Wed, 12 May 2027 00:00:00 +0000

事务让相关数据库变更一起提交，或者一起放弃。如果一次操作要求扣减一个账户、增加另一个账户，并写入流水，那么这三步就应属于同一个决定。PostgreSQL 通过 BEGIN、COMMIT 和 ROLLBACK 提供这个边界，但应用仍须把正确的语句放进去。原子执行不会自动发现漏掉的入账，也不会替业务补出一个没有编写的校验。事务保护的是被明确纳入其中的工作，而不是开发者脑中尚未落实的意图。

决定一个工作单元包含什么

普通 psql 在没有显式事务块时使用自动提交，每条语句各自处于一个事务里。因此，扣款可能已经成功提交，之后的流水插入才失败。显式分组改变了失败边界：其他事务看不到这组操作尚未提交的表数据中间状态；回滚直接丢弃其事务性变更，而不是依赖应用事后再发几条补偿更新来还原。

原子性与隔离性、持久性并不是同一件事。如果隔离级别或加锁协议不足，一组完整提交的操作仍可能基于错误的并发判断。数据库确认提交后的持久保障，也受到实际持久化配置影响。仅在代码里找到 BEGIN，还不能回答这些问题。同样，PostgreSQL 的每条语句本来就运行在事务中，读取也不例外；显式读事务可以用于重复读取快照或事务局部设置，不能一概视为无用开销。

坏掉的样子

PostgreSQL 中未处理的 SQL 错误通常会让显式事务块进入失败状态。客户端必须整体回滚，或者回滚到适用的早期保存点，才能恢复正常执行。关闭客户端的遇错停止功能，并不会修复服务器端已经失败的事务。如果把这种连接直接还给连接池，下一个请求可能接着遇到失败状态，而不是从干净边界开始。

服务器明确拒绝提交，与提交确认在网络中丢失，是不同证据。如果连接在等待 COMMIT 回复时断开，客户端可能不知道数据库是否已先完成提交。盲目重发支付可能导致重复操作。持久的操作标识和结果核对用于处理这种不确定性；普通回滚语义不能证明一个暂时无法联系的服务器究竟完成了什么。不能把所有客户端报错都解释成“肯定什么也没发生”。

快速验证

在可丢弃的 PostgreSQL 18 数据库中打开新的 psql -X -v ON_ERROR_STOP=1 会话，运行下面代码。临时表让这些账户编号只属于本会话。代码仅在两个刻意制造的失败周围关闭遇错停止，以便观察 SQLSTATE，随后立即重新开启。

\set ON_ERROR_STOP on
CREATE TEMP TABLE accounts (id integer PRIMARY KEY,balance integer CHECK(balance>=0));
CREATE TEMP TABLE ledger (id integer PRIMARY KEY,amount integer CHECK(amount>0));
INSERT INTO accounts VALUES (1,100),(2,100);
BEGIN;
UPDATE accounts SET balance=balance-20 WHERE id=1;
UPDATE accounts SET balance=balance+20 WHERE id=2;
INSERT INTO ledger VALUES (1,20);
COMMIT;
SELECT id,balance FROM accounts ORDER BY id;
BEGIN;
UPDATE accounts SET balance=balance-30 WHERE id=1;
\set ON_ERROR_STOP off
INSERT INTO ledger VALUES (1,30);
\echo duplicate_error :SQLSTATE
SELECT balance FROM accounts WHERE id=1;
\echo aborted_error :SQLSTATE
\set ON_ERROR_STOP on
ROLLBACK;
SELECT id,balance FROM accounts ORDER BY id;
SELECT count(*) AS ledger_rows FROM ledger;
DO $$ BEGIN
 IF (SELECT array_agg(balance ORDER BY id) FROM accounts) IS DISTINCT FROM ARRAY[80,120]
 OR (SELECT count(*) FROM ledger) <> 1
 OR (SELECT amount FROM ledger WHERE id=1) IS DISTINCT FROM 20 THEN
 RAISE EXCEPTION 'partial transfer survived';
 END IF;
END $$;
DROP TABLE ledger,accounts;

第一个事务提交后，余额是八十和一百二十，流水表有一行。第二个事务又扣减三十，接着尝试复用流水编号一。PostgreSQL 18.6 返回唯一性错误 23505；紧跟着的普通读取返回 25P02，证明即使客户端继续发送命令，服务器中的事务也已经处于失败状态。这个阶段看不到正常读取结果，不能误以为失败只影响那一条插入。

回滚后，余额仍然是八十和一百二十，流水仍只有一行，第二次扣款没有保留下来。断言检查整个相关状态，而不是仅凭看见错误就认定回滚一定正确。最后显式删除临时夹具；关闭会话也会移除这些临时表。实验把成功提交、数据库拒绝和清理后的结果分开展示，便于判断每一步实际发生了什么。

这是一项受控的原子性实验，不是完整转账服务。真实操作还应验证目标账户存在、影响行数符合预期、金额满足业务要求，并保护并发决策。否则事务完全可能把一组本来就错误的变更原子提交。原子性不能替代输入校验、行数检查或隔离协议，但可以让这些已经写清楚的步骤共享一个可靠提交边界。

让恢复遵守同一份契约

保存点允许撤销指定范围的工作，同时保留更早的事务性变更。只有部分成功本来就是允许结果时，这才符合业务意图。对于本例，吞掉必需的流水失败后继续提交扣款，就违反了操作契约。数据库过程块捕获异常时，也可能形成更小的回滚范围，因此需要沿真正的异常处理路径理解结果，不能只看最外层有没有事务。

序列已经发出的号码，以及发送邮件等外部动作，不会随着表写入回滚而撤销。可能重试的尝试应避免直接携带不可逆外部效果，或者使用持久协议进行协调。短而明确的事务让提交决定更容易理解；经过检查的结果和清楚的恢复路径，则确保这个决定仍然表达应用真正需要的工作。

来源

PostgreSQL 18：事务，原子分组与回滚边界，已核验 2026-09-10。
PostgreSQL 18：事务隔离，可见性与序列的非事务性行为，已核验 2026-09-10。
PostgreSQL 18：SAVEPOINT，事务内有意保留部分工作的回滚，已核验 2026-09-10。

事务可能失败，剩下的就靠你重试

Mon, 01 Feb 2027 00:00:00 +0000

PostgreSQL 中，另一个事务修改了同一行，不代表当前事务必然失败。结果取决于隔离级别、语句怎样使用数据，以及竞争者最终提交了什么。把所有碰撞都归成“等一下就好”，会掩盖无效输入，也可能重复使用已经过时的业务决策。需要定义的重试单位，是包含相关读取、判断与写入的一次完整操作。

坏掉的样子

已提交读下，普通查询使用本条语句的快照。更新遇到竞争写者时，可以先等待，再针对对方提交后的行版本重新检查条件。因此，两个把字段加一的更新完全可能先后成功。另一个常见写法却不同：客户端先读取数字，在内存里算好绝对值，稍后再把那个常量写回。数据库不会自动替客户端重算这段业务逻辑，也不能把这两种写法混为一谈。

可重复读在事务第一条非事务控制语句处建立快照，随后通常沿用。如果目标行在这个快照之后被别人修改并提交，当前事务尝试更新时就可能立即收到序列化失败。可串行化还会识别跨不同行形成的依赖异常。它们都没有承诺“只有提交才报错”，隔离更强也不等于每个负载都会更早、更频繁地失败。执行语句与提交事务这两个位置都必须检查结果。

诊断时应记录第一次错误的 SQLSTATE、隔离级别和操作标识。后续查询出现的失败事务状态只是前面错误的结果；如果日志只留下最后一条查询，就可能把真正导致中止的原因覆盖掉。

保存点可以让某些语句错误恢复后继续较早的工作，但不能代替序列化失败后从新事务快照开始的完整重试。继续使用原来的读取与判断，可能再次作出失效决策。自动重试循环中的外部副作用，也必须有自己的去重契约；数据库回滚不会自动撤回已经发出的邮件或其他系统已接受的操作。

快速验证

准备 PostgreSQL 18 的可丢弃数据库，用两个全新的 psql -X -v ON_ERROR_STOP=1 连接，分别记作甲和乙。严格按下面的先后顺序执行，未明确开启事务时，乙保持自动提交。甲先建立独立实验模式和计数器，不要把示例放进生产库：

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

甲开启已提交读事务并读取零。读取完成后先不要提交，让乙获得插入调度的机会：

BEGIN ISOLATION LEVEL READ COMMITTED;
SELECT n FROM conflict_demo.counter WHERE id=1;

乙把数字加一并提交，返回一：

UPDATE conflict_demo.counter SET n=n+1 WHERE id=1 RETURNING n;

甲再执行字段加一，返回二，然后提交。这个结果说明甲较早的查询没有冻结后续更新所使用的行值：

UPDATE conflict_demo.counter SET n=n+1 WHERE id=1 RETURNING n;
COMMIT;

等甲提交后，乙把数据归零，以便下一轮只改变隔离级别，不混入第一轮的累计值：

UPDATE conflict_demo.counter SET n=0 WHERE id=1;

甲改用可重复读，并通过读取零建立事务快照。只执行开始事务而没有读数据，不能代替这里明确的快照边界：

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT n FROM conflict_demo.counter WHERE id=1;

乙再次加一并提交，返回一：

UPDATE conflict_demo.counter SET n=n+1 WHERE id=1 RETURNING n;

甲执行同样的更新。为观察预期错误和随后失败状态，暂时关闭客户端遇错停止选项；演示完成立即恢复，再回滚：

\set ON_ERROR_STOP off
UPDATE conflict_demo.counter SET n=n+1 WHERE id=1;
\echo update_state :SQLSTATE
SELECT n FROM conflict_demo.counter WHERE id=1;
\echo transaction_state :SQLSTATE
\set ON_ERROR_STOP on
ROLLBACK;

本轮核对了原有双会话调度与文档，未重新执行；预期更新返回 40001，后续查询返回 25P02，表示事务已经失败。此时根本还没有执行提交，所以错误不只会在提交阶段出现。恢复客户端选项不会修复服务器中的失败事务；继续发送查询也不能获得新的业务快照。这里需要的是回滚，而不是把失败的那一句反复塞进原事务。

乙的竞争写入已经结束。甲现在从事务起点重试，重新读取数字、重新更新并提交：

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT n FROM conflict_demo.counter WHERE id=1;
UPDATE conflict_demo.counter SET n=n+1 WHERE id=1 RETURNING n;
COMMIT;

新读取返回一，更新返回二。乙最后核对已提交结果并删除本次实验模式：

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

最终的二分别包含双方各一次成功提交的增量；失败的尝试没有额外贡献一次加法。如果得到其他结果，先核对两个终端是否连接同一数据库、隔离级别是否正确、重置是否发生在甲提交之后，以及是否误用了第三个连接。这里的判据是完整调度和最终数据，不能只凭终端最后显示了一个数字就认定冲突处理正确。

定义完整的重试边界

收到序列化失败后，应开启新事务，连同决定键值、金额或目标行的读取与判断一起重做。死锁也可能适合整笔重试，但仍要设置次数和耗时预算。重放可能重新扫描大量数据、占用连接并再次碰撞，并非天然便宜，更不能保证最终成功。连接归还池之前应结束失败事务；预算用完时应向上层保留最终错误，不能把重试耗尽伪装成已经完成。

唯一约束错误不能一律当作瞬态事件。用户重复提交一个永久标识时，等待不会让它变成合法数据；若键值确实来自之前的查询，才可能需要针对该操作重新计算。错误码分类必须结合真实业务，而不是将所有数据库异常放进同一个循环。

还有一种情况需要单独处理：提交时连接断开，客户端没有收到确认。服务器可能已经完成提交，也可能没有完成，客户端此刻不知道结果。这不同于明确收到服务器拒绝事务的错误。支付、发信等外部可见动作，应结合操作标识与持久化结果消除歧义，再决定是否继续执行，不能仅凭“没有收到成功”就重复整笔副作用。

来源

PostgreSQL 18 事务隔离，语句快照及并发更新行为，已核验 2026-10-15。
PostgreSQL 18 序列化失败处理，完整事务重试及错误分类，已核验 2026-10-15。

文件锁保护共同协议中的特定对象

Sat, 05 Dec 2026 00:00:00 +0000

文件锁协调的是一组参与者：大家约定锁哪个对象、何时获取锁，以及哪些操作必须放在临界区内。Linux 提供多种锁接口，它们的所有权和释放规则并不相同。选一个文件名，再调用名称里带 lock 的函数，并不足以构成正确协议；还必须明确底层对象、锁的种类，以及相关每份引用的寿命，否则看起来都成功加锁的程序仍可能同时修改同一份逻辑数据。

坏掉的样子

在本实验使用的 Linux 本地文件系统上，flock 提供建议式互斥。另一个请求冲突锁的进程会等待或失败，但完全没有请求锁的普通写入仍然可以进行。因此，文件锁不会赋予内容隐私，也不会自动限制所有能够打开文件的程序。只有参与者实际遵循共同协议，互斥才能保护需要保持一致的数据操作。

如果更新通过新 inode 替换原路径，直接锁数据文件就会出现对象分离。已有锁仍关联旧的打开文件描述，后续打开者却访问替换后的文件，并可能成功获取另一把锁。两个写者都以为自己独占同一份逻辑文档，实际锁住的却是不同对象。路径名称稳定，并不意味着路径背后的文件身份稳定。

传统 POSIX 记录锁还具有容易忽略的寿命规则：锁属于进程，该进程关闭任何一个指向该文件的描述符，都会释放它在该文件上持有的记录锁。因此，某个库独立打开并关闭同一 inode，也可能使程序其他位置持有的锁失效。这与通过打开文件描述拥有锁的 flock 不同，不能把两套释放规则混用。还要注意，通过任意复制引用显式解锁，也会释放同一把 flock；其他复制描述符仍然打开，并不能抵消显式解锁。

快速验证

把脚本保存为 locking.py，在一次性 Linux 环境中运行 python3 locking.py。实测环境为 Linux 6.12.76、Python 3.11.2 和本地 tmpfs。每个竞争锁的请求都在独立子进程中执行，并使用非阻塞获取，因此预期冲突会产生可检查结果，不会让演示一直挂起：

from pathlib import Path
from tempfile import TemporaryDirectory
import fcntl,os,subprocess,sys

probe_code=r'''
import fcntl,sys
with open(sys.argv[1],'r+') as handle:
 try:
 if sys.argv[2]=='flock':fcntl.flock(handle,fcntl.LOCK_EX|fcntl.LOCK_NB)
 else:fcntl.lockf(handle,fcntl.LOCK_EX|fcntl.LOCK_NB,1,int(sys.argv[3]),0)
 except BlockingIOError:print('blocked')
 else:print('acquired')
'''
def probe(path,kind='flock',start=0):
 result=subprocess.run([sys.executable,'-c',probe_code,str(path),kind,str(start)],capture_output=True,text=True,timeout=5)
 assert result.returncode==0,result.stderr
 return result.stdout.strip()
with TemporaryDirectory(prefix='xbcatm-locks-') as directory:
 root=Path(directory);target=root/'data';target.write_text('original')
 handle=target.open('r+');fcntl.flock(handle,fcntl.LOCK_EX)
 assert probe(target)=='blocked'
 subprocess.run([sys.executable,'-c',"from pathlib import Path;import sys;Path(sys.argv[1]).write_text('uncooperative')",str(target)],capture_output=True,text=True,check=True)
 handle.seek(0);assert handle.read()=='uncooperative'
 duplicate=os.dup(handle.fileno());handle.close()
 try:assert probe(target)=='blocked'
 finally:os.close(duplicate)
 assert probe(target)=='acquired'
 print('flock blocks cooperating contenders but not ordinary writes; dup retains the same lock')
 with target.open('r+') as handle:
 fcntl.flock(handle,fcntl.LOCK_EX)
 replacement=root/'replacement';replacement.write_text('new inode');replacement.replace(target)
 assert os.fstat(handle.fileno()).st_ino!=target.stat().st_ino
 assert probe(target)=='acquired'
 lockfile=root/'stable.lock';lockfile.touch()
 with lockfile.open('r+') as handle:
 fcntl.flock(handle,fcntl.LOCK_EX)
 replacement.write_text('next inode');replacement.replace(target)
 assert probe(lockfile)=='blocked'
 assert probe(lockfile)=='acquired'
 print('replacing locked data changes the inode; a separate stable lock file protects that replacement protocol')
 first=os.open(target,os.O_RDWR);second=os.open(target,os.O_RDWR)
 try:
 fcntl.lockf(first,fcntl.LOCK_EX|fcntl.LOCK_NB,1,0,0)
 assert probe(target,'record',0)=='blocked' and probe(target,'record',1)=='acquired'
 os.close(second);second=None
 assert probe(target,'record',0)=='acquired'
 print('POSIX record locks permit disjoint bytes; closing another descriptor to the inode releases process-owned locks')
 finally:
 if second is not None:os.close(second)
 os.close(first)

首先，父进程持有排他 flock，遵守协议的子进程报告 blocked。另一个子进程完全不请求锁就写入文件，父进程随后读到修改后的内容。同一个文件、同一组权限下的两个结果，分别证明互斥确实存在，以及它的建议式边界。不能只展示一个竞争者失败，就推断所有普通读写也会被锁阻止。

父进程接着复制描述符，并关闭最初的包装对象。竞争者仍被阻止，因为复制引用继续指向带锁的打开文件描述。直到最后这份复制引用关闭，下一次竞争才成功。只统计包装对象，或者认为第一次 close 一定释放锁，都会误判真实寿命；资源管理必须追踪仍然存在的打开引用。

随后，父进程锁住数据文件，再用新文件原子替换其路径。描述符报告的 inode，与此时按路径查到的 inode 不同。子进程打开该路径，并成功获取自己的锁。原子替换保证名字在替换过程中可用，却不会把旧打开描述上的锁搬到新 inode；这正是“同名所以同锁”推理失效的地方。

下一组对照使用独立的 stable.lock。所有写者约定，先锁住这个稳定对象，再替换数据路径。竞争者在替换后仍被阻止，释放后才成功。此协议成立的前提是参与者保持锁文件身份稳定；如果运行中删除再创建锁文件，就可能重现原来不同进程锁住不同对象的问题，不能把独立文件名本身当作保证。

最后通过 lockf 验证传统 POSIX 记录锁。锁住第零个字节，会阻止请求相同字节的子进程，却允许另一个子进程锁第一个字节。父进程关闭第二份独立打开的描述符后，第零字节的锁被释放，最初用于加锁的描述符此时仍然打开。最终竞争成功，直接展示了进程级记录锁的关闭语义。

明确所有参与者遵守的协议

各参与者必须使用一致的锁种类和对象。在 Linux 本地文件系统上，传统记录锁与 flock 通常是相互独立的机制，混用不能建立互斥。NFS、SMB 可能采用不同模拟方式及交互规则；把本地结果用于远程存储前，应核对实际文件系统和挂载行为，不能从函数名字相同就推断所有语义相同。

锁范围要覆盖整条需要保持的约束。只有操作真正独立时，不同记录区间才允许安全并行；共享头部或索引可能要求更广协调。与关键数据无关的慢操作应放在临界区外，需要同时取得多把锁时使用一致顺序，避免彼此等待成环。范围越小并不自动越正确，关键在于完整覆盖更新关系。

正常返回、异常和描述符转移都要定义清理规则。进程终止会按所有权规则释放内核锁，但复制或继承的引用可能延长某些锁的寿命。锁也不会让写入自动持久化，更不会修复已完成一半的更新。因此互斥还应与文件格式所需的更新、恢复协议配合，分别验证并发一致性和失败后的数据状态。

来源

flock(2)，建议锁、打开文件描述与远程文件系统差异，已核验 2026-09-12。
fcntl_locking(2)，POSIX 记录锁范围与进程所有权释放规则，已核验 2026-09-12。
rename(2)，路径替换与既有打开引用的存续，已核验 2026-09-12。

有界重试给事务一次重新执行的机会

Mon, 09 Nov 2026 00:00:00 +0000

重试可以帮助恢复因为并发而被拒绝的事务，但不能保证成功，也不会自动让外部副作用变成幂等。重试单位应包含决定写入内容的所有数据库读取与应用判断。如果新事务仍使用第一次快照算出的金额或目标值，即使执行了新的开始事务命令，也没有真正重新做出适合当前数据的决策。

坏掉的样子

PostgreSQL 用 40001 表示序列化失败，用 40P01 表示死锁。收到这些明确拒绝后，可以在回滚并检查剩余预算的前提下再次尝试完整操作。唯一约束错误却可能是永久的：同一个无效标识不会因为多等一会儿就变成合法输入。某些键值确实由此前查询结果决定，需要特定业务的重算策略，不能据此将所有异常都塞进统一重试循环。

错误既可能发生在语句执行期间，也可能出现在提交阶段。服务器明确拒绝事务，与客户端等待提交确认时连接断开，是两种不同情况。后一种可能已经提交，只是确认没有传回来；盲目重放就可能重复操作。在数据库事务之外已经完成的支付、发信等动作，也不会随着数据库回滚自动撤销。循环本身既不能回收这些副作用，也不能凭空识别重复。

快速验证

准备 Linux 或 macOS 上的 Python 3，以及可通过命令路径运行的 PostgreSQL 18 客户端 psql。设置 PGDATABASE、PGHOST 及必要连接参数，明确指向允许创建模式的可丢弃数据库。提前配置好认证，示例禁止交互式密码提示。把下面的程序保存为 retry-demo.py，再执行 python3 retry-demo.py。它创建并删除自己的实验模式；如果同名模式已经存在，初始化会失败，不能拿已有业务模式充当实验数据。

import os
import random
import re
import selectors
import subprocess
import time

PSQL = ['psql', '-X', '-w', '-qAt', '-v', 'ON_ERROR_STOP=1', '-v', 'VERBOSITY=sqlstate']
ENV = dict(os.environ, PGCONNECT_TIMEOUT='2')


def run(sql):
 return subprocess.run(PSQL, input=sql, text=True, capture_output=True,
 check=True, timeout=5, env=ENV).stdout.strip()


def read_value(worker):
 deadline = time.monotonic() + 5
 data = bytearray()
 with selectors.DefaultSelector() as ready:
 ready.register(worker.stdout, selectors.EVENT_READ)
 while b'\n' not in data:
 remaining = deadline - time.monotonic()
 if remaining <= 0 or not ready.select(remaining):
 raise TimeoutError('Initial read was not confirmed')
 chunk = os.read(worker.stdout.fileno(), 4096)
 if not chunk:
 raise RuntimeError('Connection ended before initial read')
 data.extend(chunk)
 return int(data.strip())


def attempt(mode, number):
 worker = subprocess.Popen(PSQL, stdin=subprocess.PIPE, stdout=subprocess.PIPE,
 stderr=subprocess.PIPE, text=True, env=ENV)
 try:
 worker.stdin.write("SET statement_timeout='1s';\n"
 'BEGIN ISOLATION LEVEL REPEATABLE READ;\n'
 'SELECT n FROM retry_demo.counter WHERE id=1;\n')
 worker.stdin.flush()
 observed = read_value(worker)
 # A real second connection commits after this attempt's snapshot.
 if mode == 'always' or (mode == 'once' and number == 1):
 run('UPDATE retry_demo.counter SET n=n+1 WHERE id=1;')
 statement = ('INSERT INTO retry_demo.counter VALUES (1,99);' if mode == 'permanent'
 else f'UPDATE retry_demo.counter SET n={observed + 1} WHERE id=1;')
 finish = r'''
\set ON_ERROR_STOP off
__STATEMENT__
\if :ERROR
 \echo ATTEMPT :SQLSTATE
 ROLLBACK;
\else
 COMMIT;
 \if :ERROR
 \echo ATTEMPT :SQLSTATE
 \else
 \echo ATTEMPT 00000
 \endif
\endif
'''.replace('__STATEMENT__', statement)
 output, _ = worker.communicate(finish, timeout=5)
 match = re.fullmatch(r'ATTEMPT ([0-9A-Z]{5})', output.strip())
 if worker.returncode != 0 or match is None:
 raise RuntimeError('No confirmed transaction outcome; do not replay blindly')
 return match[1], observed
 finally:
 if worker.poll() is None:
 worker.kill()
 worker.communicate()


def increment(mode):
 observations = []
 for number in range(1, 4):
 state, observed = attempt(mode, number)
 observations.append(observed)
 if state not in {'40001', '40P01'} or number == 3:
 return {'attempts': number, 'state': state, 'reads': observations}
 time.sleep(random.uniform(0, 0.01 * 2 ** (number - 1)))


run('CREATE SCHEMA retry_demo; '
 'CREATE TABLE retry_demo.counter (id integer PRIMARY KEY,n integer); '
 'INSERT INTO retry_demo.counter VALUES (1,0);')
try:
 cases = [
 ('once', {'attempts': 2, 'state': '00000', 'reads': [0, 1]}, 2),
 ('permanent', {'attempts': 1, 'state': '23505', 'reads': [0]}, 0),
 ('always', {'attempts': 3, 'state': '40001', 'reads': [0, 1, 2]}, 3),
 ]
 for mode, expected, expected_value in cases:
 run('UPDATE retry_demo.counter SET n=0 WHERE id=1;')
 result = increment(mode)
 value = int(run('SELECT n FROM retry_demo.counter WHERE id=1;'))
 assert result == expected and value == expected_value, (mode, result, value)
 print(mode, result, 'stored', value)
finally:
 run('DROP SCHEMA retry_demo CASCADE;')

程序使用真实的两条数据库连接。每次尝试都开启可重复读事务，先读计数值，再由应用算出要写入的绝对值。竞争连接可以在读取之后、更新之前提交一次增量，迫使原快照下的更新失败。这种调度刻意检查“重试有没有重新读取和计算”，而不只是看程序有没有再次发送更新语句。

第一种情况只制造一次冲突。预期尝试两次，最终状态成功，两次读取依次为零和一，数据库最终存储二。其中一次增量来自竞争连接，另一次来自应用成功的重试。被拒绝的第一次尝试没有贡献任何提交。如果第二次只是复用原先算好的值，就不能保留两次合法增量的结果，因此最终数据也是判断重试边界的重要证据。

第二种情况制造永久错误：向已有主键再次插入相同标识。预期只尝试一次，状态为 23505，读取零，存储仍为零。分类器应立即停止，而不是把三次机会全部浪费在未改变的无效输入上。此时不能报告应用完成了加一，也不能仅因为客户端没有崩溃就把业务状态改成成功。

第三种情况在每次尝试中都安排竞争者先提交。预期尝试三次后退出，最终仍是 40001，读取依次为零、一、二，存储值为三。这里的三次增量全部属于竞争连接，应用自己的操作一次也没有提交。这是达到预算上限的失败结果，不是“重试终于成功”。断言同时检查控制流程报告与持久化数据，因为单看表里的数字无法知道是哪一方完成了操作。

让错误处理覆盖完整决策

示例从客户端取得结构化错误码，再输出专用结果标记，没有根据本地化错误文字猜测类型。预期语句错误后执行回滚，提交阶段则单独检查。若缺少确认、进程异常退出或传输等待超时，异常会离开重试分类器，不能被随意当作一次可安全重放的并发拒绝。首次读取与进程完成分别设置了等待边界，避免实验无期限挂在一个阶段。

真实应用应使用数据库驱动的事务接口和结构化异常接口，而不是直接复制这个进程调度工具。请求总预算还应包含获取连接、全部尝试以及退避时间；调用方取消后要停止继续重放，并记录尝试次数和最终错误。随机退避有助于打散同时重试的请求，却不能修复永久占用、保证公平，或让有限次数必然成功。

对外部可见操作，应使用稳定操作标识和可查询的持久化结果。提交结果不确定时，先核对结果，再决定是否重新发起非幂等动作。不可逆副作用不应直接放进会被多次执行的回调，除非相应的交付协议已经明确处理重复。让一次失败尝试可以正确退出、让重复决策基于新状态、让未知结果得到核实，才构成可靠恢复；循环次数和短暂睡眠只是其中负责安排时间的部分。

来源

PostgreSQL 18 序列化失败处理，重试错误分类和完整事务重算，已核验 2026-09-10。
PostgreSQL 18 事务隔离，实验使用的快照冲突规则，已核验 2026-09-10。
PostgreSQL 18 psql，错误状态变量、条件执行和客户端错误处理，已核验 2026-09-10。

锁与租约驯服并发写入

Sun, 04 Oct 2026 00:00:00 +0000

锁与租约用于协调共享资源访问，但具体故障行为取决于实现。本文关注互斥写入，锁本身也可以有共享模式；租约则给有效权限增加期限。熟悉的名字或一个超时值，都不能单独证明延迟写入者在交接之后不会破坏数据。设计前应明确保护什么资源、由谁执行拒绝，以及失败之后如何结束所有权。

锁有明确的生命周期

持有者崩溃后，锁并不一定永远留下。PostgreSQL 会话级咨询锁会在会话结束时释放，事务级咨询锁会在事务结束时释放。远程连接已经坏掉，服务器却尚未发现，可能导致等待持续一段时间，但这与完全没有清理机制不同。等待获取锁的超时，也不同于已经取得的所有权自行到期，不能把两种时间限制混为一谈。

单进程内互斥锁可能很合适，但死锁和线程停顿仍然存在。跨进程操作也可能更适合操作系统锁或数据库锁，而不是应用租约。应根据资源、所有权范围与恢复语义选择，不能套用“只要分布式就必须有租约”的规则，也不能因为线程属于同一进程就假定持有者永远不会失去进展。

咨询锁只约束遵守协议的参与者。忽略锁的代码仍可能访问它本来有权限触碰的资源。数据库对数据操作强制执行的锁，与外部工作者约定的主身份，具有不同的执行点。需要明确究竟哪个组件阻止冲突操作，不能仅依赖每个调用方在出错、暂停和重启之后都继续自觉遵守规则。

租约允许稍后交接

协调者可以授予截止时间之前的权限、接受及时续约，并在过期后允许另一轮获取。这样能够在持有者消失后恢复，而不必等它主动释放。然而，过期不会停止已经暂停的进程、撤回已经发送的请求，也不会取消另一项服务正在执行的写入。权限失效与旧工作实际结束之间，仍然可能存在很长的间隔。

每次写入前检查所有权，仍留下检查与效果之间的窗口。围栏协议让资源端参与，拒绝过时的获取代次。如果独立资源只记住自己已经见过的最大令牌，那么旧令牌是在更新令牌到达该资源后才被识别为过时；这个机制本身不会在所有租约刚过期的瞬间就知道它已经无效。不能把收到新代次后的拒绝，夸大为实时租约校验。

续约和释放也需要携带每次获取独有的身份。拥有者名称可能复用：工作者 B 上一次获取留下的延迟释放，不能释放 B 后来取得的新租约。Redis 按值比较后删除的模式展示了这种获取身份检查，但随机所有权值并不自动具有大小顺序，也不能直接当成严格递增的围栏号。

续约存在不确定性

续约余量应根据调度延迟、网络延迟、暂停以及协议的时钟假设选择。每个 TTL 的三分之一续一次，可以是一项运维选择，却不是正确性定理。十秒租约也不保证服务一定在十秒内完全恢复；协调者不可用、重试、调度和资源恢复都会增加额外时间，应分别测量这些等待，而不是把 TTL 直接写成故障恢复上限。

续约超时意味着结果可能未知，不一定证明协调者拒绝续约。一旦无法建立安全权限，持有者应停止发起新的工作；但尝试取消，不证明已经在途的效果也停下了。重新获取必须取得新身份，资源端仍需执行相应的旧请求拒绝规则。否则客户端看起来已经恢复正常，却可能仍有旧工作迟到并覆盖结果。

坏掉的样子

旧任务可以在另一持有者开始后恢复执行，如果存储接受旧请求，它仍然可能覆盖新数据。客户端检查尤其怕发生在检查刚通过之后的暂停。实验应在真正执行效果的位置重现迟到写入，而不只是观察客户端计时器报过期，否则最重要的写入竞争仍未被覆盖。

时钟比较需要明确模型。墙钟跳变、走时速率差异与不同时间原点，都可能破坏截止时间计算。本地时钟偏快不必然延长租约；若双方比较同一个绝对截止值，偏快反而可能使它提前过期。单调经过时间可以避免墙钟跳变，却不自动消除所有协议时序假设。缩短 TTL 也不是普遍补救办法，还可能增加误判与反复交接。

续约循环静默失败、TTL 太短、遗漏释放和延迟重复释放影响不同状态转换，应分别测试。每轮获取都保存对应令牌，不要把可复用的拥有者字符串当作充分授权。应用取消与租约失效同样是两种操作，需要分别确认它们对已有工作的影响，而不能一条日志写着取消就宣布所有效果已经停止。

快速验证

保存为 lease.py，运行 python3 lease.py。顺序模型把协调者和资源合在一个对象里，使用手动推进、不可后退的时钟。在每次模型写入时，所有权、期限与代次和写入本身一起检查。这个契约故意强于只记录已收到令牌的独立资源，因此不能把模型的立即过期检查当成普通分布式围栏系统已经提供的功能。

class LeaseLostError(RuntimeError):
 pass


class LeaseStore:
 """Serial, co-located coordinator and resource; one manual clock."""
 def __init__(self):
 self.holder, self.expiry, self.fence, self.data = None, 0, 0, None
 self.clock = 0

 def observe(self, now):
 if now < self.clock:
 raise ValueError("clock moved backwards")
 self.clock = now

 def acquire(self, owner, ttl, now):
 self.observe(now)
 if ttl <= 0:
 raise ValueError("TTL must be positive")
 if self.holder is None or now >= self.expiry:
 self.holder, self.expiry = owner, now + ttl
 self.fence += 1
 return self.fence
 return None

 def valid(self, owner, token, now):
 return self.holder == owner and token == self.fence and now < self.expiry

 def renew(self, owner, token, ttl, now):
 self.observe(now)
 if ttl <= 0:
 raise ValueError("TTL must be positive")
 if not self.valid(owner, token, now):
 return False
 self.expiry = now + ttl
 return True

 def release(self, owner, token, now):
 self.observe(now)
 if not self.valid(owner, token, now):
 return False
 self.holder = None
 return True

 def write(self, owner, token, value, now):
 self.observe(now)
 if not self.valid(owner, token, now):
 raise LeaseLostError("expired, wrong owner, or stale acquisition")
 self.data = value


def rejected(store, owner, token, now):
 before = store.data
 try:
 store.write(owner, token, "forbidden", now)
 except LeaseLostError:
 assert store.data == before
 else:
 raise AssertionError("invalid write accepted")


store = LeaseStore()
a = store.acquire("A", 5, 0)
assert a == 1
store.write("A", a, "a-1", 2)
assert store.renew("A", a, 5, 4) and store.expiry == 9
store.write("A", a, "a-2", 8)
rejected(store, "A", a, 9) # Equality is expired.
assert not store.renew("A", a, 5, 9)
b = store.acquire("B", 5, 10)
assert b == 2
store.write("B", b, "b-1", 11)
rejected(store, "B", a, 12)
rejected(store, "A", a, 12)
assert store.acquire("C", 5, 12) is None
assert not store.release("A", a, 12)
assert store.release("B", b, 12)
new_b = store.acquire("B", 5, 13)
assert new_b == 3
assert not store.release("B", b, 13)
assert not store.renew("B", b, 5, 13)
store.write("B", new_b, "new-b", 14)
assert store.release("B", new_b, 14)
c = store.acquire("C", 5, 14)
assert c == 4
store.write("C", c, "c-1", 15)
assert store.data == "c-1"
for operation in (lambda: store.acquire("D", 0, 15),
 lambda: store.renew("C", c, -1, 15),
 lambda: store.write("C", c, "backwards", 14)):
 try:
 operation()
 except ValueError:
 pass
 else:
 raise AssertionError("invalid TTL or backwards time accepted")
print("PASS: renewal, expiry, fencing, same-owner reacquisition, and input guards")

预期出现 PASS 行。续约把截止时间从五推进到九，恰好等于九就已过期；错误拥有者与旧令牌都不能改动数据。B 随后用新令牌重新获取，携带旧令牌的迟到释放和续约均失败。零或负 TTL、后退时间也被拒绝。这些负例明确检查了交接和同名重新获取，而不是只验证正常释放路径。

两种语言的修订示例均已在 Linux、Python 3.12.14 下通过。证据仅覆盖顺序模型状态转换，没有验证网络共识、持久围栏、真实时钟、PostgreSQL 锁、Redis 可用性或生产并发。应保留这些边界，避免将小型确定性模型的成功误写成整个跨机器协议的证明。

来源

分布式系统：租约与围栏(Martin Kleppmann)，锁为何漏、租约为何帮得上，已核验 2026-10-02。
PostgreSQL：咨询锁，应用级锁，已核验 2026-10-02。
Redis：SET 与锁，用带时限的键搭锁，已核验 2026-10-02。

死锁：两个写者在互相等待

Tue, 11 Aug 2026 00:00:00 +0000

死锁需要不兼容的等待关系形成一个环。一个事务持有行锁、另一个事务等待时，持锁者仍可能正常结束并放锁；双方各自握着对方必须获得的资源时，就无法沿当前路径完成。PostgreSQL 会检测这种循环，中止其中一个事务，让另一个继续。应用需要区分服务器明确拒绝事务与普通的慢等待，而不是把所有停顿都叫作死锁。

坏掉的样子

即使没有显式锁语句，更新行也会获取锁。因此，两段看起来简单的更新，如果以相反顺序访问两行，就可能互相等待。参与者更多、包含外键检查、触发器、建议锁或锁模式升级时，依赖环会更难看见。给某一段行编号排序，只能解决这部分访问顺序，不能据此证明整个业务路径再也没有死锁。

数据库检测到死锁时返回 40P01。应用不能依赖“后开始者必输”或“工作量少的一方会被中止”之类规则。锁等待超时、语句超时也可能先于死锁检测触发，返回另一种错误。因此必须查看实际错误码和服务器诊断，再判断发生了什么。没有看到死锁码，并不等于没有形成过循环；重试了一次，也不代表原来的取锁顺序已经修好。

快速验证

准备同一个 PostgreSQL 18 可丢弃数据库，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。甲创建两行数据，并显示死锁检测等待参数：

CREATE SCHEMA deadlock_demo;
CREATE TABLE deadlock_demo.items (id integer PRIMARY KEY,n integer);
INSERT INTO deadlock_demo.items VALUES (1,0),(2,0);
SHOW deadlock_timeout;

本次环境显示一秒。下面给语句十秒预算，让检测有时间发生，并确保没有更短的锁超时抢先干预。如果你的检测间隔更长，应相应调整实验预算。甲记录自己要增加的十，并先更新第一行，暂不提交：

\set delta 10
SET statement_timeout='10s';
BEGIN;
UPDATE deadlock_demo.items SET n=n+:delta WHERE id=1;

乙记录自己要增加的一百，先更新第二行，也保持事务打开：

\set delta 100
SET statement_timeout='10s';
BEGIN;
UPDATE deadlock_demo.items SET n=n+:delta WHERE id=2;

甲继续更新第二行，此时会等待乙的锁。提交这个块后，应立即切换到乙终端，不要等甲这条更新结束：

\set ON_ERROR_STOP off
UPDATE deadlock_demo.items SET n=n+:delta WHERE id=2;
\echo second_result :SQLSTATE
\set ON_ERROR_STOP on

甲等待期间，乙申请更新第一行：

\set ON_ERROR_STOP off
UPDATE deadlock_demo.items SET n=n+:delta WHERE id=1;
\echo second_result :SQLSTATE
\set ON_ERROR_STOP on

现在循环等待已经形成。一个终端输出死锁错误，另一个最终输出成功状态，甲或乙都可能成为失败者。演示中暂时允许预期错误继续显示，只是为了看清两种结果，不会决定数据库选谁中止。先在收到 40P01 的失败终端执行回滚，结束已经失败的事务：

ROLLBACK;

再在得到成功状态的终端提交完整操作：

COMMIT;

之后任选一个终端读取两行：

SELECT id,n FROM deadlock_demo.items ORDER BY id;

如果甲获胜，两行都是十；如果乙获胜，两行都是一百。不应出现一行十、一行一百的混合结果。失败者第一条已经成功执行的更新，也随着事务中止被撤销；不能把“第一条语句曾返回成功”记成业务操作已经提交了一半。这里的结果验证的是完整事务的原子性，而不只是两条连接最终都恢复响应。

现在回到失败者原来的终端，重试整个操作。该终端保存的增量变量仍然代表它原本要做的工作。先按编号顺序锁定两行，再执行更新并提交：

BEGIN;
SELECT id FROM deadlock_demo.items ORDER BY id FOR UPDATE;
UPDATE deadlock_demo.items SET n=n+:delta;
COMMIT;

锁定查询依次返回一和二。此时胜者已经提交，所以重试能够完成。最后任选终端核对两笔增量恰好各保留一次，并清理实验：

SELECT id,n FROM deadlock_demo.items ORDER BY id;
DO $$ BEGIN
 IF (SELECT array_agg(n ORDER BY id) FROM deadlock_demo.items) IS DISTINCT FROM ARRAY[110,110] THEN
 RAISE EXCEPTION 'deadlock recovery lost or duplicated work';
 END IF;
END $$;
DROP SCHEMA deadlock_demo CASCADE;

两行都必须是一百一十。断言不仅检查有没有错误，还能发现少做一次或重复一次的恢复问题。整个实验应保留原来的两个会话；如果临时开第三个终端执行重试，它没有失败者保留的客户端变量，也就不知道该恢复十还是一百。恢复对象由失败的完整操作决定，不能随意把成功者也重放一遍。

沿完整路径避免重复发生

当所有参与者都遵守同样的顺序，且行标识保持稳定时，固定顺序可以消除这里展示的双行循环。真实系统需要把这套顺序扩展到相关的其他资源，并有意识地选择所需锁模式。触发器和约束检查可能隐式访问另一张表；如果只审查表面上的两条更新，局部有序仍然无法排除其他路径引入的循环。

缩短事务、避免持锁等待用户或远程服务，可以减少占用窗口。收到服务器明确的死锁拒绝后，应回滚，再连同读取和业务判断一起重试。高竞争时要有次数、时间预算与随机退避，预算用完则上报最终错误。频繁死锁仍然需要检查访问顺序和负载分布，因为检测和重试都会消耗时间，有限重试更不承诺一定成功。这个实验展示了可核对的恢复结果，不是对任意工作负载都免于死锁的保证。

来源

PostgreSQL 18 显式锁，死锁循环、不可依赖的受害者选择及取锁顺序，已核验 2026-09-10。
PostgreSQL 18 序列化失败处理，并发失败后重试完整事务，已核验 2026-09-10。

MVCC 根据可见性规则选择行版本

Sat, 08 Aug 2026 00:00:00 +0000

多版本并发控制让 PostgreSQL 保留不同的行版本，再判断查询可以看到哪些版本。普通读者可以继续读取较早已提交的版本，同时另一个事务写出新版本。这减少了读写之间的冲突，但不表示每个事务都永久拥有一幅固定画面。快照寿命取决于隔离级别，而且事务能看到自己此前的修改，即使其他事务尚看不到。把这些边界说清楚，才能理解读取结果为何既稳定又可能变化。

可见性跟随快照

在读已提交级别，普通读取通常每条语句取得一个新快照。PostgreSQL 的可重复读则复用事务第一条非事务控制语句建立的快照。仅仅发送 BEGIN，还没有建立实际读取使用的边界。因此，一个较早开始、较晚才第一次读取的事务，可能看到这两个时刻之间已经完成的提交。“事务启动时间”与“读取快照已经建立”不能随意混用。

更新会创建一个新行版本。可见性规则决定旧快照是否仍读取之前的版本，而新快照是否看到更新。元组物理上仍然存在，并不足以说明当前查询能看到它；SQL 也不是直接返回数据页上最新写下的字节。只有结合事务状态与快照，才能判断哪一版记录属于这次读取的结果。

事务自己的修改，是简单“历史照片”比喻的重要例外。即使快照早已建立，事务仍然可以读到之后由自己插入的记录。它看到的数据，可能同时包含其他事务的较早状态与自己的新工作。这种行为让事务能够实际完成读写操作，但不能把它误解为外部世界某一个已提交时刻的完整照片。理解这个例外，也能避免错误地认为自己的更新必须提交以后才可读。

坏掉的样子

普通读取取得的常规表锁不会阻塞正常行更新，但锁并没有消失。两个写者仍可能争用同一行；SELECT FOR UPDATE 会明确请求行锁；ACCESS EXCLUSIVE 表锁则与普通读者冲突。因此，MVCC 不承诺所有带有 SELECT 的命令都永远不等待。是否阻塞还需要看语句请求的锁以及当前其他操作。

旧快照还可能让读者需要的旧行版本继续保留。只要某个相关快照仍可能看到该版本，清理就不能直接移除它。空间压力取决于更新量、保留版本和清理进度，不只是打开了多少个事务。再启动一次清理，并不会让仍然活跃的快照忘掉自己的可见性要求；需要沿保留原因调查，而不是只盯住维护命令有没有运行。

快速验证

历史双会话测试保持原样，本次没有重跑。单用户后端不能证明并发快照行为。

在同一个可丢弃的 PostgreSQL 18 数据库中，打开甲、乙两个新的 psql -X -v ON_ERROR_STOP=1 会话，使用相同角色，显式事务之外保持正常自动提交。模式名称必须尚未被使用。按下面顺序执行，让乙在甲的读事务仍然打开时完成提交。

在乙中建立一条已经提交的原始记录。

CREATE SCHEMA mvcc_visibility_demo;
CREATE TABLE mvcc_visibility_demo.items (id integer PRIMARY KEY,note text);
INSERT INTO mvcc_visibility_demo.items VALUES (1,'old');

在甲中通过读取建立可重复读快照。

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT id,note FROM mvcc_visibility_demo.items ORDER BY id;

在乙中更新原记录、插入第二条记录，并查看已经提交的结果。

UPDATE mvcc_visibility_demo.items SET note='new' WHERE id=1;
INSERT INTO mvcc_visibility_demo.items VALUES (2,'other');
SELECT id,note FROM mvcc_visibility_demo.items ORDER BY id;

在甲中重读，插入属于自己的第三条记录，再读一次并提交。

SELECT id,note FROM mvcc_visibility_demo.items ORDER BY id;
INSERT INTO mvcc_visibility_demo.items VALUES (3,'mine');
SELECT id,note FROM mvcc_visibility_demo.items ORDER BY id;
COMMIT;

甲提交后使用新语句再次读取，随后在乙中清理。

SELECT id,note FROM mvcc_visibility_demo.items ORDER BY id;

DROP SCHEMA mvcc_visibility_demo CASCADE;

PostgreSQL 18.6 实测中，甲第一次读取返回 (1,old)。乙不需要等待这个普通读者结束，就完成了更新和插入，并看到 (1,new) 与 (2,other)。甲再次读取时仍然只有 (1,old)。当甲插入自己的记录后，它能看到 (1,old) 和 (3,mine)，但乙插入的第二行仍不属于甲的快照。这同时展示了他人提交的隔离与自身修改的可见性。

甲提交后，新语句能看到当前的三行：(1,new)、(2,other) 和 (3,mine)。因此，变化并不是某个旧版本在同一快照中忽然变新，而是读取边界已经改变。若只打开一个会话、不安排并发更新，就无法验证上述区别，也不能由一个静态查询证明 MVCC 在并发下的行为。

在用途结束时结束快照

需要这种读取契约时，才为相应工作选择事务级快照，并在操作完成后及时结束。调查长期快照时，应同时查看写入量与清理进度，而不是假设历史版本会立即自行消失。可重复的可见性也不会阻止所有跨行业务异常；某项操作仍可能需要可串行化隔离、显式协调或约束。MVCC 提供行版本可见性，完整的应用并发契约才决定基于这些记录作出的判断是否正确。

来源

PostgreSQL 18：MVCC 介绍，行版本与读取并发，已核验 2026-09-10。
PostgreSQL 18：事务隔离，快照寿命与自身写入可见性，已核验 2026-09-10。
PostgreSQL 18：显式锁，读者与写者的锁冲突，已核验 2026-09-10。
PostgreSQL 18：常规清理，保留可见版本并回收过期记录，已核验 2026-09-10。

并发 · XB 现场笔记

建议锁寿命属于连接或事务

坏掉的样子

快速验证

让持有寿命覆盖完整操作

来源

事务让提交是原子的

决定一个工作单元包含什么

坏掉的样子

快速验证

让恢复遵守同一份契约

来源

事务可能失败，剩下的就靠你重试

坏掉的样子

快速验证

定义完整的重试边界

来源

文件锁保护共同协议中的特定对象

坏掉的样子

快速验证

明确所有参与者遵守的协议

来源

有界重试给事务一次重新执行的机会

坏掉的样子

快速验证

让错误处理覆盖完整决策

来源

锁与租约驯服并发写入

锁有明确的生命周期

租约允许稍后交接

续约存在不确定性

坏掉的样子

快速验证

延伸阅读

来源

死锁：两个写者在互相等待

坏掉的样子

快速验证

沿完整路径避免重复发生

来源

MVCC 根据可见性规则选择行版本

可见性跟随快照

坏掉的样子

快速验证

在用途结束时结束快照

来源