PostgreSQL中“事务中空闲”会话虽不执行语句，但仍持有锁和连接槽，并可能阻止VACUUM清理死行。仅执行SELECT的会话在READ COMMITTED隔离级别下会阻塞ALTER TABLE并连带阻塞后续查询；REPEATABLE READ或已写入的会话还会阻碍清理。该超时默认值为0，可按角色设置idle_in_transaction_session_timeout，超时后连接被终止、事务回滚。

实测 PostgreSQL 17 多租户单租户删除：级联删除与逐表删除耗时相同，瓶颈在外键触发器，需为外键列建索引。删除不阻塞其他租户读写，但阻塞该租户写入并阻碍 vacuum。批量删除应按执行计划选批次，过大反而全表扫描更慢。删除后数据库不缩小，空间留给新租户，数据仍残留在 WAL、备份、审计日志中。分区 DROP 最快，但需先删引用分区，且加排他锁，应设 lock_timeout。

PostgreSQL 行锁不存于共享内存，而是写入元组头：t_xmax 记录加锁事务 ID，t_infomask 位标记锁类型。四种锁强度由三位编码，FOR UPDATE 与键更新、删除冲突。多事务同时加锁时用 MultiXactId 指向磁盘成员列表，外键检查自动加 FOR KEY SHARE。锁提交后标记仍留在页上，直到 VACUUM 清理。大量短事务与长事务并发会快速消耗 multixact 成员空间，需监控避免超限。

PostgreSQL通过MVCC实现多版本并发控制，每次更新会保留旧版本元组，导致表膨胀。事务使用XID和命令ID跟踪可见性，快照隔离决定数据可见性。VACUUM清理死元组，但受事务地平线限制，长事务会阻止清理。子事务和HOT链影响清理效率，需定期维护以避免性能下降。

本文讨论了PostgreSQL中的VACUUM过程，包括堆扫描、索引清理和堆清理三个阶段。VACUUM通过清理死元组和更新可见性图来回收空间，提高数据库性能。文章还强调了VACUUM与VACUUM FULL的区别，后者用于压缩文件大小。

PostgreSQL的锁机制可能导致阻塞和死锁。文章讨论了五种常见的锁行为，包括ACCESS EXCLUSIVE锁的排队、外键约束引发的隐性死锁、唯一约束检查导致的死锁、自动清理的特殊行为以及VACUUM的隐藏ACCESS EXCLUSIVE阶段。建议通过设置锁超时和监控活动来减轻这些问题。

PostgreSQL的多版本并发控制（MVCC）允许读者和写者并行操作而不互相阻塞。每个元组包含两个事务ID（t_xmin和t_xmax），用于确定可见性。更新操作创建新版本并标记旧版本，VACUUM负责清理无效元组，但长时间运行的事务可能会阻止清理，导致空间浪费。不同的隔离级别影响快照的捕获时机，从而影响查询结果。

PostgreSQL中的表膨胀是由于UPDATE或DELETE操作产生的“死元组”未被VACUUM回收，导致数据文件增大。造成膨胀的原因包括长时间运行的事务、未提交的准备事务、启用hot_standby_feedback的备用服务器查询和逻辑复制延迟。解决方法是终止阻止VACUUM的事务或查询。

许多开发者误以为运行VACUUM可以保持PostgreSQL数据库健康，但VACUUM只能删除死元组，无法重组B树索引，导致索引膨胀。处理堆膨胀适合使用VACUUM，而索引膨胀则需手动使用REINDEX。应监控索引状态，及时处理膨胀问题。

PostgreSQL中的“数据库不接受命令”错误通常与事务ID环绕有关。解决方法包括处理旧的准备事务、结束长时间运行的事务、删除过期的复制槽，并执行VACUUM命令。避免使用单用户模式和VACUUM FULL，以减少停机时间，并确保自动清理配置正确，以防未来问题。

我从杜塞尔多夫机场出发前往pgday.at，因技术问题延误，但最终顺利抵达维也纳。在会议上，我意外成为演讲者，分享了现代PostgreSQL VACUUM的内容。活动精彩，结识了许多社区成员，最后在博物馆度过了愉快的早晨。

在PGConf.DE会议前，我参加了汉堡的Debian MiniDebConf，随后前往柏林。会议吸引了340名与会者，讨论了PostgreSQL的VACUUM演变、现代SSL和高可用性策略等主题，促进了社区交流。尽管回程遇到交通堵塞，但整体经历丰富而有意义。