PostgreSQL隔离级别的行为
我正在通读PostgreSQL Manual的13.2节，但发现文本描述不够清晰，也缺乏示例。
例如，以下两段并不清楚谁在学习PostgreSQL：
带有ON CONFLICT DO UPDATE子句的
INSERT的行为类似。在Read Committed模式下，建议插入的每一行都将插入或更新。除非存在不相关的错误，否则这两种结果中的一种是可以保证的。如果冲突是由另一个事务引起的，而该事务的影响对INSERT是不可见的，则UPDATE子句将影响该行，即使该行的任何版本通常对命令都不可见。“
和
可重复读取模式提供了严格的保证，以确保每个事务都能看到完全稳定的数据库视图。然而，此视图不一定总是与同一级别的并发事务的某些串行(一次一个)执行保持一致。
有没有人能举例说明这两段话的内容？
有人知道在哪里可以找到PostgreSQL隔离级别行为的正式描述吗？我之所以寻找它，是因为它是一个高级主题，我相信正式的描述将有助于阐明它是如何工作的，从而有助于避免事务之间的并发错误。
UPDATE：我的另一个疑问是，当可序列化事务可以与其他隔离级别的其他事务并发运行时，如何根据数据库机制决定提交或中止它的方式来处理可序列化事务？数据库是否决定可序列化事务的结果，就好像其他事务也是以可序列化隔离运行的一样？
谢谢
更新2：到目前为止，关于隔离级别的实现细节，我找到的最好的是PostgreSQL Wiki Serializable Page。
回答 2
Stack Overflow用户
发布于 2018-06-07 13:36:34
READ COMMITTED：每条SQL语句都会生成一个新的数据库快照，因此在提交时，每条语句都会同时看到并发事务所做的更改。没有序列化错误可以occur.REPEATABLE READ：事务中的第一条语句获取为整个事务保留的数据库的快照，因此所有语句都看到数据库的相同状态。如果在拍摄快照后尝试修改已由并发事务修改的行，则可能会发生序列化错误。这种隔离级别并不比READ COMMITTED.SERIALIZABLE：更昂贵，任何可能导致与事务的某些串行执行顺序不一致的结果的事务都将因序列化错误而中止。可能会有误报。此隔离级别比其他隔离级别更昂贵。
具体问题的答案如下：
读已提交隔离中的
INSERT ... ON CONFLICT：
如果事务1已插入行，但尚未提交，则运行INSERT ... ON CONFLICT的事务2将等待，直到事务1已提交或回滚，然后根据需要更新或插入。不能发生违反约束的情况。
- 批处理作业和
REPEATABLE READ：
这一段很暗；忽略它。它试图说明两个并发的可重复读取转换可以产生与任何串行执行都不一致的结果。
一个更好的示例可能是两个并发事务，这两个事务都读取相同的数据，并根据读取的结果对其执行更新。这些事务中的每一个都看不到另一个事务的修改。
有关更详细的examples.
- Update问题，请查看“可序列化”下的PostgreSQL维基：
这个问题对我来说不是很清楚。
可序列化事务采用特殊的"SI“锁，这些锁跟踪读写访问并在提交后存活。它们不会阻塞其他会话，但用于确定是否存在冲突。只有当所有并发事务都使用可序列化隔离级别时，可序列化隔离级别才能正常工作。
Stack Overflow用户
发布于 2018-06-08 19:18:39
关于更新中的问题
数据库是否决定可序列化事务的结果，就好像其他事务也是以可序列化隔离运行的一样？“
答案是否定的。
仅在可序列化隔离级别的并发事务之间验证可序列化。例如，假设两个事务T1和T2交错，如下所示：
T1: begin
T1: set transaction isolation level read committed;
T1: update addresses set street = 'Sun street' where id = 1
T2: begin
T2: set transaction isolation level serializable;
T2: select street from addresses where id = 1
T2: update addresses set street = 'Sea street' where id = 2
T1: select street from addresses where id = 2
T1: commit
T2: commitT1和T2都会提交。但是，如果T1设置为可序列化隔离，则T2将中止。
https://stackoverflow.com/questions/50725403
复制相似问题