从 go 同时测试`FOR UPDATE`

Question

I have a procedure with SELECT FOR UPDATE lock. I would like to test it from go concurrently in order to make sure that lock is actually there.

I am using this:

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;

That's pretty dump sample I can provide at this time, but it shows that there is lock must be acquired to queue sp calls.

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
}

Also, I expect 2 goroutines to see test data populated in first transaction, but sp() fails because it does not see data, which is odd because read uncommitted level means it can see dirty data (by insertPersonFixtures ).

A by @Brits:

The SQL standard defines one additional level, READ UNCOMMITTED. In PostgreSQL READ UNCOMMITTED is treated as READ COMMITTED.

What is wrong with this code or perhaps it's a bad way to test RDBMS locks this way? Or I misunderstood isolation levels? In my example I expect the 2nd goroutine to timeout and signal that there is a lock exist.

Is there a straightforward way to clean up database after each test? I am not sure running truncate for each table is easy. Obviously after such idiocy from equal read committed and uncommitted and lack of proper nested transactions it all turns into a mess.

Answer 1

From the PostgreSQL docs :

The SQL standard defines one additional level, READ UNCOMMITTED. In PostgreSQL READ UNCOMMITTED is treated as READ COMMITTED.

So it looks like what you are seeing is to be expected (however as you did not provide much info on sp() its difficult to comment - providing a Minimal, Reproducible Example might result in a better answer).

Note you have a typo in tx.Exec("CAL sp()") - checking for errors returned from the various database calls would improve this test case.

Additional info following your update:

tx.ExecContext(ctx, "CALL sp(`john`, 20)") should be err = tx.ExecContext(ctx, "CALL sp(`john`, 20)") (otherwise you are checking the error returned by begin transaction - best to check both).

You can perform your test by setting a short timeout (say one second - something like tx.ExecContext(ctx, "SET statement_timeout = 1000) ) before doing the second update and then check that the call fails. this will work because the first transaction will maintain a lock until the second one is committed/rolled back.

Is there a straightforward way to clean up database after each test?

This depends on your requirements; in this case rolling back the transactions will remove your test data. Truncate works OK but generally you would want some test data to remain so it's not ideal. I generally restore a backup or use a docker container (data restored as part of the build).