Golang 并发 SQL 事务

Question

遇到并发和 SQL 事务的问题。我有下面的（存根）代码（为了清楚起见，删除了错误检查和这样的代码）：dao, _ := sql.Open("postgres", args)tx1 := dao.Begin()res, _ := tx1.Exec("UPDATE <...>", args...)// error checktx2 := dao.Begin()res, _ = tx2.Exec("UPDATE <same>", args...)_ = tx1.Commit()_ = tx2.Commit()这发生在单元测试中。这个想法是强制并发失败，因为两个 Exec 正在尝试更新同一行，以确保给出正确的冲突错误响应。但是，第二个 Exec 永久阻塞。据我所知，这种类型的阻塞只有在数据库没有数据库连接时才会发生，但事务都应该在它们自己的（独占）连接中运行，而且我没有在任何地方设置最大连接（我也试过将它设置为 100 之类的，没有效果）。这是奇怪的部分。如果我将 tx2 Exec() 和 Commit() 分离到一个单独的 goroutine 中，并带有一个同步通道来阻止主线程运行 tx1.Commit() 直到 tx2 运行它的 Exec()，同样的事情会发生，无限期地阻塞tx2.Exec()。如果我使用 time.Sleep() 而不是同步通道，tx2.Exec 会阻塞，直到睡眠完成并运行 tx1.Commit()，然后以预期的错误 ( pq: could not serialize access due to concurrent update)我是否遗漏了有关 golang 的 SQL 包或 postgres 驱动程序如何处理连接池的信息？为什么在提交第一个事务之前，第二个事务 Exec 会阻塞？两个事务可以同时运行，并且无论哪个提交（或者它开始？）首先获胜，这不是事务的重点吗？

Answer 1

经过进一步研究，看起来这实际上不是 Golang、SQL 或 PQ 包的问题。这是 PostgreSQL 中固有的（和设计的）行为：

UPDATE、DELETE、SELECT FOR UPDATE 和 SELECT FOR SHARE 命令在搜索目标行方面的行为与 SELECT 相同：它们只会找到在命令开始时提交的目标行。但是，这样的目标行在找到时可能已经被另一个并发事务更新（或删除或锁定）。在这种情况下，潜在的更新者将等待第一个更新事务提交或回滚（如果它仍在进行中）。

http://www.postgresql.org/docs/9.1/static/transaction-iso.html

所以这个块发生在 Postgres 中，而不是 Go 中。这可以通过运行并发事务来确认，这些事务使用psql. 第二个更新/插入/删除将阻塞，直到调用第一个的事务调用 COMMIT 或 ROLLBACK。