# Test SKIP LOCKED with multixact locks.

setup
{
  CREATE TABLE queue (
	id	int		PRIMARY KEY,
	data			text	NOT NULL,
	status			text	NOT NULL
  );
  INSERT INTO queue VALUES (1, 'foo', 'NEW'), (2, 'bar', 'NEW');
}

teardown
{
  DROP TABLE queue;
}

session s1
setup		{ BEGIN; }
step s1a	{ SELECT * FROM queue ORDER BY id FOR SHARE SKIP LOCKED LIMIT 1; }
step s1b	{ COMMIT; }

session s2
setup		{ BEGIN; }
step s2a	{ SELECT * FROM queue ORDER BY id FOR SHARE SKIP LOCKED LIMIT 1; }
step s2b	{ SELECT * FROM queue ORDER BY id FOR UPDATE SKIP LOCKED LIMIT 1; }
step s2c	{ COMMIT; }

# s1 and s2 both get SHARE lock, creating a multixact lock, then s2
# tries to update to UPDATE but skips the record because it can't
# acquire a multixact lock
permutation s1a s2a s2b s1b s2c

# the same but with the SHARE locks acquired in a different order, so
# s2 again skips because it can't acquired a multixact lock
permutation s2a s1a s2b s1b s2c

# s2 acquires SHARE then UPDATE, then s1 tries to acquire SHARE but
# can't so skips the first record because it can't acquire a regular
# lock
permutation s2a s2b s1a s1b s2c