该PostgreSQL代码可以创建哪些并发问题？

Question

好的，这是模式，这很容易解释：

STORE(storeID, name, city)
PRODUCT(productID, name, brand)
PRODUCT_FOR_SALE(productID, storeID, price)

我有2笔交易： T1和T2 。
T1将在“伦敦”的任何商店中出售的任何产品的价格提高5％。
对于价格大于等于$ 1050的任何产品， T2会将价格降低10％

我被要求告诉他们它们可能导致哪种并发异常 ，以及应该对哪种事务应用哪种隔离级别以使其安全。

没有给出交易的代码，但我想应该是这样的：

# T1:
BEGIN;
    UPDATE product_for_sale 
    SET    price = price + ((price/100) *5)
    WHERE  storeID IN (SELECT storeID FROM store WHERE city='London')
COMMIT;

# T2:
BEGIN;
    UPDATE product_for_sale
    SET    price = price - (price/10)
    WHERE  price >= 1050
COMMIT;

我对“ READ COMMITTED提交”（默认）可能发生的“猜测”是：
考虑产品P，在“伦敦”以$ 1049的价格出售

• 两项交易都开始
• 他们都考虑了行集：T1将考虑在伦敦销售的所有产品（包括P），T2将考虑价格在1050美元或更高（不包括P）的产品
• T1提交并将P的价格设置为$ 1101，但是由于P不在T2的行开头，因此更改未引起注意，T2提交时未考虑它

如果我不搞砸定义，那应该是幻影读取的情况，如果我将T2设置为ISOLATION LEVEL REPEATABLE READ ，它将得到修复

Answer 1

首先，不清楚并发问题的含义。 它可能是：

1. 可能是个问题，但是PostgreSQL自动处理了该问题，因此不会出现问题。

2. 可能会导致意外错误或不良结果的事物。

对于1.，这由序列化试图同时修改同一行的事务的锁来处理。

我认为您对2更感兴趣。

您描述的内容可能会发生，但这不是并发问题。 这仅表示T1在逻辑上先于T2。 这在所有隔离级别上都可以正常工作。

我可能会丢失一些东西，但是我在这里看到的唯一潜在问题是两个语句之间的死锁：

它们都可以更新几行，因此可能发生的情况是，其中一个先更新X行，然后尝试更新Y行，而另一行已经更新了该行。 然后，第一条语句被阻止。 现在，第二条语句想要更新Y行，并且也被阻塞了。

这种死锁在一秒钟后被死锁解析器通过杀死一条错误语句而被打破。

请注意，死锁也不是真正的问题，您的代码要做的就是重复失败的事务。