]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix thinko in lock mode enum
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Sun, 4 Jan 2015 18:48:29 +0000 (15:48 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Sun, 4 Jan 2015 18:48:29 +0000 (15:48 -0300)
commit51742063be4fd8d58fb8571e559fe8ca0abbbb57
treede06919385c5f7d1a8668fda87745097be33f684
parent7ced1b6c52b0e933813af7389c6ff77cf699f564
Fix thinko in lock mode enum

Commit 0e5680f4737a9c6aa94aa9e77543e5de60411322 contained a thinko
mixing LOCKMODE with LockTupleMode.  This caused misbehavior in the case
where a tuple is marked with a multixact with at most a FOR SHARE lock,
and another transaction tries to acquire a FOR NO KEY EXCLUSIVE lock;
this case should block but doesn't.

Include a new isolation tester spec file to explicitely try all the
tuple lock combinations; without the fix it shows the problem:

    starting permutation: s1_begin s1_lcksvpt s1_tuplock2 s2_tuplock3 s1_commit
    step s1_begin: BEGIN;
    step s1_lcksvpt: SELECT * FROM multixact_conflict FOR KEY SHARE; SAVEPOINT foo;
    a

    1
    step s1_tuplock2: SELECT * FROM multixact_conflict FOR SHARE;
    a

    1
    step s2_tuplock3: SELECT * FROM multixact_conflict FOR NO KEY UPDATE;
    a

    1
    step s1_commit: COMMIT;

With the fixed code, step s2_tuplock3 blocks until session 1 commits,
which is the correct behavior.

All other cases behave correctly.

Backpatch to 9.3, like the commit that introduced the problem.
src/backend/access/heap/heapam.c
src/test/isolation/expected/tuplelock-conflict.out [new file with mode: 0644]
src/test/isolation/isolation_schedule
src/test/isolation/specs/tuplelock-conflict.spec [new file with mode: 0644]