Postgresql 中文操作指南

13.6. Caveats #

某些 DDL 命令（目前仅为 TRUNCATE 和 ALTER TABLE 的表重写形式）不是 MVCC 安全的。这意味着，如果截断或重写提交后，表在并发事务中将显示为空（如果这些事务正在使用在 DDL 命令提交之前拍摄的快照）。只有在 DDL 命令启动之前未访问过有问题的表的事务才会遇到此问题——这样做的任何事务都会至少持有 ACCESS SHARE 表锁，这将阻止 DDL 命令，直到该事务完成。因而，这些命令不会导致目标表上连续查询表内容有任何明显的不一致，但它们可能会导致目标表和数据库中其他表的内容之间出现可见的不一致。

Some DDL commands, currently only TRUNCATE and the table-rewriting forms of ALTER TABLE, are not MVCC-safe. This means that after the truncation or rewrite commits, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the DDL command committed. This will only be an issue for a transaction that did not access the table in question before the DDL command started — any transaction that has done so would hold at least an ACCESS SHARE table lock, which would block the DDL command until that transaction completes. So these commands will not cause any apparent inconsistency in the table contents for successive queries on the target table, but they could cause visible inconsistency between the contents of the target table and other tables in the database.

尚未将可串行化事务隔离级别支持添加到热备用复制目标（在 Section 27.4 中描述）。热备用模式下当前支持的最严格的隔离级别为可重复读取。虽然在主要数据库上使用可串行化事务执行所有永久数据库写入将确保所有备用最终达到一致的状态，但对备用运行的可重复读取事务有时会看到与主要数据库上事务的任何串行执行不一致的瞬态状态。

Support for the Serializable transaction isolation level has not yet been added to hot standby replication targets (described in Section 27.4). The strictest isolation level currently supported in hot standby mode is Repeatable Read. While performing all permanent database writes within Serializable transactions on the primary will ensure that all standbys will eventually reach a consistent state, a Repeatable Read transaction run on the standby can sometimes see a transient state that is inconsistent with any serial execution of the transactions on the primary.

当前事务的隔离级别不会用于系统目录的内部访问。这意味着新创建的数据库对象(例如表) 对并发的可重复读取和可串行化事务是可见的，即使它们包含的行不可见。相反，在较高的隔离级别中，明确检查系统目录的查询不会看到表示同时创建的数据库对象的行的。

Internal access to the system catalogs is not done using the isolation level of the current transaction. This means that newly created database objects such as tables are visible to concurrent Repeatable Read and Serializable transactions, even though the rows they contain are not. In contrast, queries that explicitly examine the system catalogs don’t see rows representing concurrently created database objects, in the higher isolation levels.