问PostgreSQL - MVCC (多版本并发控制)-什么时候获得实际锁？

EN

根据我的理解，postgres使用两个额外的字段Xmin和Xmax来实现mvcc，假设我们有带有id和name列的Employee表。

下面是一些crud操作以及它们是如何并发工作的(考虑隔离级别= READ_COMMITTED)，问题是何时在何处获得实际锁。

1. Insert ->新事务插入新记录，在其他事务提交之前该记录不可见，因此在本例中不存在任何问题，也不需要锁或版本控制。假设id = 1，则插入name = "aa“。Postgres为mvcc =当前txn id (假设为100)和Xmax =0/null添加了两个额外列。

id  |   name | Xmin | Xmax
------------------------------
1   |   aa   | 100  | null

具有并发读取的

1. Update -

a)。一个新的事务开始将名称更新为"bb“(对于id = 1)。同时，还有另一个事务开始读取相同的数据。

b)。一个新的元组( postgres中表示一行的不可变对象)将使用Xmin =当前事务id (假设200)和Xmax = null以及id = 1、name = bb创建。此外，id =1的旧版本也会被更新为具有Xmax = 200。returns看到Xmin = 100的旧版本的数据并返回。在这种情况下是否需要任何锁？我认为不是，但它可能会更新旧元组的Xmax.

下面是多个版本的相同记录(只是为了解释)，最新版本具有Xmax = null。

id  |   name | Xmin | Xmax
------------------------------
1   |   aa   | 100  | 200
1   |   bb   | 200  | null

具有并发更新的

1. Update -

a)。事务(使用txn id = 300)开始将id =1更新为name = cc。另一个事务(txn id = 400)开始将相同的记录(id = 1)更新为name = dd。如果这个场景通过创建新元组和标记旧元组的Xmax来以同样的方式进行，那么我认为它会产生问题，因为300和400都将创建一个新的元组并标记旧元组的Xmax = txn id。在这种情况下，更新可能会松动。

在这个场景中，排他锁是由第一个txn和其他并发更新txns获得的，等待任何正在进行的txn完成，或者有其他一些处理它的方式?。