Update ch07.md

remove redundant *

ch07.md

@@ -121,7 +121,7 @@ SELECT COUNT(*) FROM emails WHERE recipient_id = 2 AND unread_flag = true
 
 在多对象事务中，一个关键点是如何确定多个操作是否属于同一事务：
 
-1. 从**物理上来考虑。**可以通过 TCP 连接来确定，在同一个连接中，`BEGIN TRANSACTION` 和 `COMMIT`语句之间的所有内容，可以认为属于同一个事务。但会有一些 corner case，如在客户端提交请求后，服务器确认提交之前，网络中断，连接断开，此时客户端则无从得知事务是否被成功提交。
+1. 从**物理上来考虑**。可以通过 TCP 连接来确定，在同一个连接中，`BEGIN TRANSACTION` 和 `COMMIT`语句之间的所有内容，可以认为属于同一个事务。但会有一些 corner case，如在客户端提交请求后，服务器确认提交之前，网络中断，连接断开，此时客户端则无从得知事务是否被成功提交。
 2. **从逻辑上来考虑**。使用事务管理器，为每个事务分配一个唯一标识符，从而对操作进行分组。
 
 实际中基本上使用第二种方法。
@@ -708,7 +708,7 @@ SSI，顾名思义，基于快照隔离。即在 SSI 隔离级别中，所有的
 2. 决策：考察读到的数据，做出某种决策。
 3. 写入：将对应决策造成结果写回数据库。
 
-即，这里面存在一个因果关系，读为因，写为果。如果在提交时，发现决策的**前提**（*premise，*如：“今天有两名医生排到了值班”）不再满足，则后面写入失去意义。因此为了提供可串行化的隔离级别，需要识别这种因果关系，并且能够在提交时检测前提是否失效，以决定是否中止事务。
+即，这里面存在一个因果关系，读为因，写为果。如果在提交时，发现决策的**前提**（*premise*，如：“今天有两名医生排到了值班”）不再满足，则后面写入失去意义。因此为了提供可串行化的隔离级别，需要识别这种因果关系，并且能够在提交时检测前提是否失效，以决定是否中止事务。
 
 那如何检测前提是否失效呢？
 
@@ -754,7 +754,7 @@ SSI，顾名思义，基于快照隔离。即在 SSI 隔离级别中，所有的
 1. 如果细粒度跟踪，虽然能精确的检测到真正的冲突，减少重试，但会有显著的记录开销。
 2. 如果粗粒度的跟踪，虽然性能会好，但会导致更多的冲突和重试。
 
-在某些情况下，即使一个事务读到的信息被另外一个事务的写入覆盖，仍然能保证可串行化的隔离级别。这取决于事务读到这些信息后，用来做了什么，*PostgreSQL* 便根据这个原则来减少不必要的重试*。*
+在某些情况下，即使一个事务读到的信息被另外一个事务的写入覆盖，仍然能保证可串行化的隔离级别。这取决于事务读到这些信息后，用来做了什么，*PostgreSQL* 便根据这个原则来减少不必要的重试。
 
 和 2PL 相比，SSI 的最大优点是，不会通过锁来阻塞有依赖关系的事务并发执行。SSI 就想运行在快照隔离级别一样，读不阻塞写，写不阻塞读。只是追踪记录，在提交时决定是否提交或重试。这种设计是的查询延迟更可预测。尤其是，只读事务可以工作在一致性快照上，而不受影响，这对读负载很重的场景很有吸引力。