| # 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 |
