事务 · XB 现场笔记

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

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

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

坏掉的样子

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

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

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

快速验证

准备同一个 PostgreSQL 18 可丢弃数据库，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。实验使用默认的零值锁超时，且没有其他会提前干预的超时设置。下面的毫秒参数只用于快速复现，不是生产建议值。甲先建立独立模式和计数表：

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;

睡眠持续二百毫秒，超过锁等待预算五十毫秒，但正常返回成功状态。没有等待锁，不能仅凭耗时长就触发锁超时。提交之后，显示的锁超时恢复为会话原来的零，因为局部设置只持续到当前事务结束。最后由甲核对数据仍为一，并清理实验：

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。

WATCH 保护 Redis 中依赖读取的更新决定

Thu, 22 Jul 2027 00:00:00 +0000

MULTI/EXEC 能阻止别的客户端命令插进队列的执行过程，却不会自动保护应用此前已经读到的值。如果两个购买方先读到相同库存，再各自写回计算结果，即使每次 SET 都放进事务，也仍然可能丢失一次更新。问题出在读取与提交之间的空隙，而不是 SET 执行得是否足够连续。

先监视，再读取依赖

WATCH 让 EXEC 变成有条件的执行：被监视的键从建立监视之后不能发生修改。因此，必须先 WATCH，再读取参与决策的数据。若键在提交前改变，Redis 拒绝整个队列并返回空响应；这只是不执行自己的队列，不会撤销竞争方已经完成的修改。

监视与事务状态都属于同一条连接。redis-py 流水线在 watch 之后保留连接，multi 之前的 GET 会立即发出，应用可以读取结果并做判断；multi 之后才转为缓冲命令，等待 execute。用上下文管理器包住一次尝试，可以在结束时重置流水线状态并释放专用连接。

凡是会影响决策的值或“不存在”条件，都要纳入监视范围。只监视库存，却忽略另一个键保存的额度，并不能保护额度判断。WATCH 也不只是比较最终字节：即便 SET 写回相同内容，也可以使监视失效；原来不存在的被监视键被创建，同样会导致冲突。本次版本中，由过期和内存淘汰引起的变化也计算在内。

重试整个决策，而不是旧计算结果

收到明确的冲突结果后，应建立新监视，重新读取依赖，再检查业务条件和计算写入值。继续使用旧库存，相当于把同一个错误判断再执行一次。EXEC 无论成功还是因监视冲突取消，都会清除监视；如果应用读完后决定放弃，也可以通过 UNWATCH 主动解除。

重试需要次数或时间上限，并让调用方知道何时已耗尽预算。热点键上的大量冲突会放大成本，即使最终没有丢数据也会增加延迟。退避可以缓和竞争，却补不上遗漏的监视键。若原生命令已经能表达所需的原子操作，应优先使用它；实验刻意拆开库存算术，是为了展示旧值覆盖问题。

监视检查通过，也不会让事务获得自动回滚能力。EXEC 内部某一条命令运行失败，其它成功命令仍可能已经生效。应校验相关数据模型并逐项检查响应，不要把数个互不相干的副作用放在一起，就称为业务上的全成全败。

坏掉的样子

先读后 WATCH，会漏掉建立监视前的那段竞争窗口。用一条连接监视、另一条连接提交，不会保护后者的队列。在重试循环中发邮件或发起支付，则可能在 Redis 拒绝本次尝试之前，就已经产生了无法随队列取消的外部效果。

还必须区分服务端明确报告的冲突与传输故障。redis-py 8.1.0 在监视期间遇到连接异常，也可能抛出 WatchError；仅凭异常类型，不能断言 EXEC 从未执行。提交之后应答丢失，需要核对业务结果或依赖幂等协议，不能无条件重新执行不可逆动作。

实验用第二条连接主动制造冲突，并断言固定版本客户端的冲突消息。这个消息比较是测试断言，不是生产错误分类方案。实验关闭网络自动重试，避免隐式重新提交干扰观察。Redis Cluster 中普通多键事务还要求相关键位于同一哈希槽，WATCH 不会额外提供跨分片事务协调器。

快速验证

需要具备 C 编译器、make、curl、tar，以及 Python 3.10 或更新版本的 POSIX 环境。此前记录在 macOS、Python 3.14.4、Redis 8.10.1 与 redis-py 8.1.0 上执行；本轮没有重跑。下面只在临时目录编译使用 libc 的 Redis 核心，并将客户端安装到虚拟环境，不安装系统服务。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

在同一终端使用 "$redis_lab/venv/bin/python" 运行下方代码。它在 /tmp 创建私有 Unix 套接字，关闭 TCP 和持久化；结束时仅停止自己启动的进程并清理运行目录。下载阶段需要联网，实验不会连接已有 Redis 实例。

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance():
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", "noeviction",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


with instance() as client, client.client() as rival:
 client.set("stock", 2)
 stale = int(client.get("stock"))
 assert rival.decr("stock") == 1
 with client.pipeline(transaction=True) as transaction:
 transaction.set("stock", stale - 1)
 assert transaction.execute() == [True]
 assert client.get("stock") == b"1"
 print("a stale value written inside MULTI/EXEC still loses another decrement")

 client.set("stock", 2)
 conflicts = 0
 for attempt in range(2):
 with client.pipeline(transaction=True) as transaction:
 transaction.watch("stock")
 current = int(transaction.get("stock"))
 assert current > 0
 if attempt == 0:
 assert rival.decr("stock") == 1
 transaction.multi()
 transaction.set("stock", current - 1)
 transaction.set("reservation", "accepted")
 try:
 responses = transaction.execute()
 except redis.WatchError as error:
 assert str(error) == "Watched variable changed."
 conflicts += 1
 assert client.get("stock") == b"1"
 assert client.get("reservation") is None
 continue
 assert responses == [True, True]
 break
 else:
 raise AssertionError("both attempts conflicted")
 assert conflicts == 1 and attempt == 1
 assert client.get("stock") == b"0"
 assert client.get("reservation") == b"accepted"
 print("WATCH rejects the stale queue; the second attempt rereads 1 and commits 0")

 client.set("watched", "unchanged")
 with client.pipeline(transaction=True) as transaction:
 transaction.watch("watched")
 assert transaction.get("watched") == b"unchanged"
 rival.set("watched", "unchanged")
 transaction.multi()
 transaction.set("same-value-marker", "yes")
 try:
 transaction.execute()
 except redis.WatchError as error:
 assert str(error) == "Watched variable changed."
 else:
 raise AssertionError("same-value SET did not invalidate WATCH")
 assert client.get("same-value-marker") is None
 print("WATCH detects a SET even when the resulting bytes are unchanged")

 with client.pipeline(transaction=True) as transaction:
 transaction.watch("not-yet-created")
 assert transaction.get("not-yet-created") is None
 rival.set("not-yet-created", "now-present")
 transaction.multi()
 transaction.set("absent-marker", "yes")
 try:
 transaction.execute()
 except redis.WatchError as error:
 assert str(error) == "Watched variable changed."
 else:
 raise AssertionError("creating a watched key did not invalidate WATCH")
 assert client.get("absent-marker") is None
 print("WATCH also protects a read of an absent key against later creation")

第一组先读到库存二，让竞争连接扣成一，再把根据旧值计算出的一写回事务。两个调用方都想扣一次，最后却只从二变成一。这段明确安排的执行顺序说明：不被插队的提交，修复不了事务之前已经过期的读取结果。

第二组先监视再读。故意插入的竞争扣减使第一次队列被拒绝，预订标记仍不存在，而对手把库存改成一的结果保留。第二次尝试重新监视并读到一，再一起写入零和预订标记。循环最多两次，每一次是否冲突以及最终值都由断言检查，不依赖碰运气产生竞态。

最后两组验证容易漏想的条件：写回相同字节，以及创建原本不存在的监视键。两种情况都会阻止队列里的标记落地。代码打印的四条摘要都来自响应和最终存储状态验证，而不是只看有没有抛异常。

这次验证覆盖隔离实例上的乐观冲突处理，不证明调度公平、预订恰好执行一次、网络故障恢复、持久化或集群切换。实际预订仍需要自己的业务标识，以及对提交结果未知的明确处理方式；示例中的标记键只是便于观察，不能直接当作完整订单协议。

来源

Redis 事务，乐观并发与事务失败语义，已核验 2026-10-15。
Redis WATCH，基于监视键的条件执行，已核验 2026-10-15。
Redis EXEC，空响应与执行结果，已核验 2026-10-15。
Redis UNWATCH，清除连接级监视，已核验 2026-10-15。
redis-py 8.1.0 客户端实现，即时读取、连接绑定及 WatchError 路径，已核验 2026-10-15。
Redis Cluster 规范，多键操作的哈希槽边界，已核验 2026-10-15。
Redis 8.10.1 构建说明，仅编译核心及选择分配器，已核验 2026-10-15。

Redis 事务隔离执行，但不自动回滚

Wed, 31 Mar 2027 00:00:00 +0000

Redis 事务先在一条连接上积累命令队列，再进入一个隔离的执行窗口。MULTI 开始排队，EXEC 按顺序执行已接受的命令。这里的关键保证是其它客户端的命令不能插进执行过程，而不是后面一条失败时，前面所有成功写入都能自动撤销。

入队与执行是两个阶段

QUEUED 表示服务端接受了命令，等待后续执行，并不表示这条命令想完成的写入已经成功。Redis 在接受命令时就会检查命令是否存在、参数数量是否正确；依赖当前数据的错误，例如向字符串键执行列表操作，则可能直到 EXEC 才暴露。不能笼统地把它们都称为语法错误，因为两种失败对应的队列处理方式并不相同。

在队列中发送 GET，同样先收到 QUEUED，真正的值出现在 EXEC 的结果数组里。客户端不能先读取这个排队 GET 的实际结果，再据此决定本次事务后面的命令。需要在应用内判断时，可先用 WATCH 保护读取依赖；必须在读取与写入之间分支时，可考虑有界的服务端脚本。

客户端缓冲又增加了一层。redis-py 的普通事务流水线先把命令放进本地列表，直到 execute 才发送 MULTI、各条命令与 EXEC。set 方法返回流水线对象，并不等于服务端已确认入队。下面使用专用连接读取原始响应，是为了观察协议的实际阶段，而不是把客户端的链式调用误当成服务器执行结果。

隔离从执行时开始

MULTI 不会替调用方提前锁住相关键。一个客户端仍在构造队列时，另一个客户端完全可以更新这些键。队列中的 GET 读取的是它执行时的值，不是 MULTI 开始时保存的快照；后面的 GET 也能看到本事务前面 SET 的写入。把不被插队说成启动时的一致快照，会误导依赖旧值的业务判断。

事务必须始终使用同一条连接，而且这条连接不能混入无关业务。如果连接池为 MULTI 和 EXEC 分别分配连接，它们就不属于同一个事务状态。应用代码应优先使用客户端提供的事务抽象；实验直接访问连接，只用于核验已固定版本的协议行为。

坏掉的样子

入队阶段出现错误参数数量，会让事务被标记为不可执行。随后 EXEC 返回 EXECABORT，已经排队的写入也不会发生。DISCARD 则是调用方主动清空尚未执行的队列。这两种操作都不是撤销已经执行过的命令，更不能在 EXEC 完成之后靠 DISCARD 回到原来的数据。

执行期的 WRONGTYPE 不同：失败命令在自己的结果位置返回错误，前面成功的写入保留，后续命令还会继续执行。只有检查每一个响应，才能判断业务操作是否完整成功。客户端抛异常，不能证明 Redis 停在那条命令，也不能证明整批都已回滚。

redis-py 默认的 execute 可能在处理完整事务响应后抛出 ResponseError。关闭 raise_on_error，可以把执行期错误作为结果元素取回，但并没有改变服务端的执行或回滚能力。连接问题还要单独处理：若 EXEC 已发送而应答丢失，客户端可能不知道事务是否完成。直接重发非幂等操作可能造成重复扣减。

事务的执行也应保持短小，因为执行期间其它请求需要等待。隔离保证没有替应用选择持久化、复制或故障切换策略；收到了成功响应，只能说明本次执行结果，不能据此声称数据会在所有故障下存活。

快速验证

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance():
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", "noeviction",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


def command(connection, *arguments):
 connection.send_command(*arguments)
 return connection.read_response()


with instance() as client, client.client() as queued:
 connection = queued.connection
 client.set("value", "initial")
 assert command(connection, "MULTI") == b"OK"
 assert command(connection, "GET", "value") == b"QUEUED"
 assert command(connection, "SET", "value", "own-write") == b"QUEUED"
 assert command(connection, "GET", "value") == b"QUEUED"
 assert client.get("value") == b"initial"
 client.set("value", "other-client")
 assert command(connection, "EXEC") == [b"other-client", b"OK", b"own-write"]
 assert client.get("value") == b"own-write"
 print("QUEUED does not execute; EXEC reads current state and then its own writes")

 assert command(connection, "MULTI") == b"OK"
 assert command(connection, "SET", "discarded", "yes") == b"QUEUED"
 assert command(connection, "DISCARD") == b"OK"
 assert client.get("discarded") is None
 print("DISCARD removes the unexecuted queue")

 assert command(connection, "MULTI") == b"OK"
 assert command(connection, "SET", "before-arity", "yes") == b"QUEUED"
 try:
 command(connection, "SET", "missing-value")
 except redis.ResponseError as error:
 assert "wrong number of arguments" in str(error)
 else:
 raise AssertionError("invalid SET was accepted")
 assert command(connection, "SET", "after-arity", "yes") == b"QUEUED"
 try:
 command(connection, "EXEC")
 except redis.exceptions.ExecAbortError:
 pass
 else:
 raise AssertionError("queue error did not abort EXEC")
 assert client.mget("before-arity", "after-arity") == [None, None]
 print("wrong arity fails during queueing; EXECABORT applies none of the queue")

 client.set("wrong-type", "string")
 assert command(connection, "MULTI") == b"OK"
 assert command(connection, "SET", "before-runtime", "yes") == b"QUEUED"
 assert command(connection, "LPUSH", "wrong-type", "item") == b"QUEUED"
 assert command(connection, "SET", "after-runtime", "yes") == b"QUEUED"
 responses = command(connection, "EXEC")
 assert len(responses) == 3
 assert responses[0] == responses[2] == b"OK"
 assert isinstance(responses[1], redis.ResponseError)
 assert "WRONGTYPE" in str(responses[1])
 assert client.mget("before-runtime", "wrong-type", "after-runtime") == [
 b"yes", b"string", b"yes",
 ]
 print("runtime error occupies one reply; both surrounding writes remain applied")

第一组依次排队 GET、SET、GET。在 EXEC 之前，另一条连接先把值改成 other-client，所以最终响应依次是 other-client、OK 和 own-write。执行前检查还确认排队的 SET 并未提前修改数据。这既区分了延迟执行与旧快照，也验证了事务后面的读取能够看见自己的前序写入。

DISCARD 场景留下的标记键不存在。随后，缺少值参数的 SET 在入队时立即报错，EXECABORT 之后，它前后两条已收到 QUEUED 的写入也都没有发生。这里必须查看实际键值；只看到第一条错误信息，并不足以证明整个队列确实未执行。

最后让 LPUSH 操作已有字符串，EXEC 返回三个元素：成功、WRONGTYPE、成功。前后两个标记都已写入，原字符串保持不变。四条打印摘要都放在真实响应与存储值断言之后，不是预先假设的输出。

本地实验验证的是入队与执行两个错误阶段、显式取消及执行时读取，并未模拟网络断连、崩溃恢复、集群路由或持久性。把这一机制用于不可逆业务操作之前，仍需单独验证那些边界，不能把本次断言通过扩大为完整交付保证。

来源

Redis 事务，命令入队、执行隔离与错误处理，已核验 2026-10-15。
Redis MULTI，连接级事务入口，已核验 2026-10-15。
Redis EXEC，按序返回结果与监视冲突，已核验 2026-10-15。
Redis DISCARD，丢弃未执行的命令队列，已核验 2026-10-15。
redis-py 8.1.0 客户端实现，流水线缓冲与响应处理，已核验 2026-10-15。
Redis 8.10.1 构建说明，仅编译核心及选择分配器，已核验 2026-10-15。

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

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。

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

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, 23 Aug 2026 00:00:00 +0000

选择隔离级别，应从操作必须维持的不变量出发。一致快照很有用，但两个事务可能分别作出看似合理的决定，却在一起提交后得到错误结果。PostgreSQL 的可重复读保持事务读取快照稳定，仍允许部分序列化异常。可串行化则增加依赖检测，拒绝无法解释为任何串行执行顺序的并发组合，同时要求应用处理相应重试。关键是知道业务依赖哪项保证，而不是单纯选择一个听起来更强的名称。

稳定视图与正确决策分开判断

假设有两名值班医生，要求至少一名留岗。每名医生只有在看到可用人数大于一时才允许离开。两个可重复读事务可以都看到两人，然后分别把不同医生标记为离岗。它们没有覆盖彼此的同一行，因此都可能提交，最后值班人数变成零，即使每个事务都使用了内部稳定的快照。

这叫写偏差，不是对同一行发生丢失更新。分别检查每个医生布尔字段是否合法，并没有表达“总人数至少为一”的全局规则。只保护自己正在修改的那一行，也会漏掉两个决定之间的联系。适用的序列化协议需要覆盖整个不变量，而不只是其中某个局部字段。

具体数据库实现也很重要。PostgreSQL 把读未提交映射为读已提交；它的可重复读会阻止幻读，尽管 SQL 标准允许这一等级存在幻读。这些特性仍不会消除写偏差。因此，应根据引擎文档解释隔离名称，不能假定所有数据库同名级别的实现完全一样，更不能把某一种异常被排除当成所有并发问题都解决。

坏掉的样子

把可串行化理解为数据库实际每次只执行一个事务，会误导性能判断。PostgreSQL 仍并发运行事务并跟踪依赖，某个事务可能在执行途中或提交时收到 40001。应用需要用新的读取重做完整决定，不能只重新提交，也不能继续使用被拒绝快照中计算出来的值。否则虽然换了一次事务，决策前提仍然是旧的。

可串行化也不能修复一个独自运行时就违反业务规则的事务。所有相关写入路径都必须遵守既定契约；如果另外一条不受限制的更新允许最后一名医生离岗，不变量仍会被破坏。更高隔离提供并发保证，不会自动实现尚未编写的业务逻辑。实验中的条件判断与隔离级别必须一起成立。

快速验证

在同一个可丢弃的 PostgreSQL 18 数据库中，打开甲、乙两个新的 psql -X -v ON_ERROR_STOP=1 会话，使用相同角色，显式事务外保留正常自动提交，并选用尚未使用的模式名称。严格遵守下面顺序；先让两边读取重叠，才能建立要观察的竞争决策。

在甲中创建初始值班表。

CREATE SCHEMA isolation_demo;
CREATE TABLE isolation_demo.doctors (id integer PRIMARY KEY,on_call boolean NOT NULL);
INSERT INTO isolation_demo.doctors VALUES (1,true),(2,true);

先在甲中开始事务并读取，再在乙中执行对应操作。两边人数都应为二。

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

在甲中更新第一名医生，再在乙中更新第二名。每条更新也会在自己的快照中检查人数规则。

UPDATE isolation_demo.doctors SET on_call=false WHERE id=1
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;

UPDATE isolation_demo.doctors SET on_call=false WHERE id=2
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;

先提交甲，再提交乙。两边结束后，在甲中查看已经失效的不变量并重置值班表。

COMMIT;

\set ON_ERROR_STOP off
COMMIT;
\echo commit_state :SQLSTATE
\set ON_ERROR_STOP on

SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

UPDATE isolation_demo.doctors SET on_call=true;

使用可串行化重复这组重叠决策：开始甲、开始乙、更新甲、更新乙、提交甲，最后尝试提交乙。

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

UPDATE isolation_demo.doctors SET on_call=false WHERE id=1
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;

UPDATE isolation_demo.doctors SET on_call=false WHERE id=2
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;

COMMIT;

\set ON_ERROR_STOP off
COMMIT;
\echo commit_state :SQLSTATE
\set ON_ERROR_STOP on

在甲中检查人数，在乙中以新事务重做完整决定，最后在甲中核对并清理。

SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;
UPDATE isolation_demo.doctors SET on_call=false WHERE id=2
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;
COMMIT;

SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;
DROP SCHEMA isolation_demo CASCADE;

PostgreSQL 18.6 实测中，可重复读的两个提交都成功，可用人数变成零。在受控的可串行化顺序下，甲提交成功，乙提交返回 40001，仍有一名医生留岗。代码只在需要观察的提交周围关闭遇错停止，让 psql 能打印 SQLSTATE；如果出现其他错误，不能把它当成预期的序列化拒绝。

乙重新开始完整事务后，读到只剩一名医生，带条件的更新没有返回任何行，也没有把最后一人移走。它成功提交后，最终人数仍是一。这同时验证了异常被阻止，以及拒绝后确实重新计算决定。仅仅观察到数据库抛错，还不足以证明应用恢复路径符合业务要求。

评估实际代价

依赖跟踪与重复尝试会消耗资源，显式锁则可能带来等待与协调成本，没有一种方式在所有负载下都更快。应测量真实事务组合，保持事务简短，并给重试次数和请求截止时间设置边界。先选择能够覆盖所有参与路径、维持不变量的机制，再用有代表性的工作验证争用行为，而不是为了追求抽象的并发数放弃具体正确性要求。

来源

PostgreSQL 18：事务隔离，快照隔离与可串行化依赖检查，已核验 2026-09-10。
PostgreSQL 18：序列化失败处理，SQLSTATE 分类与完整事务重试，已核验 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。