# Test SKIP LOCKED with an updated tuple chain. setup { CREATE TABLE foo ( id int PRIMARY KEY, data text NOT NULL ); INSERT INTO foo VALUES (1, 'x'), (2, 'x'); } teardown { DROP TABLE foo; } session "s1" setup { BEGIN; } step "s1a" { SELECT * FROM foo WHERE pg_advisory_lock(0) IS NOT NULL ORDER BY id LIMIT 1 FOR UPDATE SKIP LOCKED; } step "s1b" { COMMIT; } session "s2" step "s2a" { SELECT pg_advisory_lock(0); } step "s2b" { UPDATE foo SET data = data WHERE id = 1; } step "s2c" { BEGIN; } step "s2d" { UPDATE foo SET data = data WHERE id = 1; } step "s2e" { SELECT pg_advisory_unlock(0); } step "s2f" { COMMIT; } # s1 takes a snapshot but then waits on an advisory lock, then s2 # updates the row in one transaction, then again in another without # committing, before allowing s1 to proceed to try to lock a row; # because it has a snapshot that sees the older version, we reach the # waiting code in EvalPlanQualFetch which skips rows when in SKIP # LOCKED mode, so s1 sees the second row permutation "s2a" "s1a" "s2b" "s2c" "s2d" "s2e" "s1b" "s2f"