从 go 同时测试`FOR UPDATE`

Question

我有一个SELECT FOR UPDATE带锁的程序。我想同时测试它，以确保锁确实存在。我正在使用这个：CREATE TABLE IF NOT EXISTS person (  name varchar primary key);INSERT INTO person VALUES ('john');CREATE TABLE IF NOT EXISTS tickets (  name varchar PRIMARY KEY REFERENCES person,  amount integer NOT NULL);CREATE OR REPLACE PROCEDURE sp (_name varchar, _amount integer) AS$$BEGIN  -- acquire a lock on person row  PERFORM name FROM person WHERE name = _name FOR UPDATE;  INSERT INTO tickets VALUES(_name, _amount);END$$ LANGUAGE plpgsql;这是我目前可以提供的漂亮转储示例，但它表明必须获取锁才能对sp调用进行排队。func TestInsert(t *testing.T) {    tx, err := db.Begin() // Read Committed level tx    defer tx.Rollback()    insertPersonFixtures(tx) // Using this tx to fill database with test data needed by testing SP    ready1 := make(chan struct{})    ready2 := make(chan struct{})    done := make(chan struct{})    go func() {      // Must see `prepareSomeData` data in database??      tx, err := db.BeginTx(context.Background(), &sql.TxOptions{Isolation: sql.LevelReadUncommitted})      defer tx.Rollback()      tx.Exec("CALL sp('john', 10)")      ready1 <- struct{}{}      <-ready2      done <- struct{}{}    }()    go func() {      <-ready1      ctx, cancel := context.WithTimeout(context.Background(), time.Second)      defer cancel()      // Must see `prepareSomeData` data in database??      tx, err := db.BeginTx(context.Background(), &sql.TxOptions{Isolation: sql.LevelReadUncommitted})      defer tx.Rollback()      tx.ExecContext(ctx, "CALL sp(`john`, 20)")      if err == nil {            t.Error("No lock", err)        }      ready2 <- struct{}{}    }()    <-done}另外，我希望 2 个 goroutine 可以看到在第一个事务中填充的测试数据，但是sp()因为看不到数据而失败，这很奇怪，因为未提交的读取级别意味着它可以看到脏数据（按insertPersonFixtures）。@Brits 的一个：SQL 标准定义了一个附加级别，READ UNCOMMITTED。在 PostgreSQL 中，READ UNCOMMITTED 被视为 READ COMMITTED。这段代码有什么问题，或者以这种方式测试 RDBMS 锁可能是一种不好的方法？还是我误解了隔离级别？在我的示例中，我希望第二个 goroutine 超时并发出存在锁的信号。每次测试后有没有一种简单的方法来清理数据库？我不确定为每个表运行 truncate 是否容易。显然，在同等读取已提交和未提交以及缺乏适当的嵌套事务之后，这一切都变得一团糟。

Answer 1

来自PostgreSQL 文档：

SQL 标准定义了一个附加级别，READ UNCOMMITTED。在 PostgreSQL 中，READ UNCOMMITTED 被视为 READ COMMITTED。

因此，您所看到的似乎是意料之中的（但是，由于您没有提供太多关于sp()难以评论的信息 - 提供一个最小的、可重现的示例可能会产生更好的答案）。

请注意，您有一个错字tx.Exec("CAL sp()")- 检查从各种数据库调用返回的错误将改进此测试用例。

更新后的附加信息：

tx.ExecContext(ctx, "CALL sp(`john`, 20)")应该是err = tx.ExecContext(ctx, "CALL sp(`john`, 20)")（否则您正在检查 begin transaction 返回的错误 - 最好同时检查）。

您可以通过在进行第二次更新之前设置一个短暂的超时（比如一秒 - 类似tx.ExecContext(ctx, "SET statement_timeout = 1000)）来执行测试，然后检查调用是否失败。这将起作用，因为第一个事务将保持锁定，直到第二个事务被提交/回滚。

每次测试后有没有一种简单的方法来清理数据库？

这取决于您的要求；在这种情况下，回滚事务将删除您的测试数据。截断工作正常，但通常你会希望保留一些测试数据，所以它并不理想。我通常恢复备份或使用 docker 容器（作为构建的一部分恢复的数据）。