Fix FOR UPDATE NOWAIT on updated tuple chains
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 27 Aug 2014 23:15:18 +0000 (19:15 -0400)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 27 Aug 2014 23:15:18 +0000 (19:15 -0400)
commit1c9701cfe58267cf5d79543a42ee4f0967cc73ab
tree8103133b312bbe48b0aecad9a3a4fb96184fb822
parent9a2d94892f6a793d52ebabb8283b98a6e3ede3d6
Fix FOR UPDATE NOWAIT on updated tuple chains

If SELECT FOR UPDATE NOWAIT tries to lock a tuple that is concurrently
being updated, it might fail to honor its NOWAIT specification and block
instead of raising an error.

Fix by adding a no-wait flag to EvalPlanQualFetch which it can pass down
to heap_lock_tuple; also use it in EvalPlanQualFetch itself to avoid
blocking while waiting for a concurrent transaction.

Authors: Craig Ringer and Thomas Munro, tweaked by Álvaro
http://www.postgresql.org/message-id/51FB6703.9090801@2ndquadrant.com

Per Thomas Munro in the course of his SKIP LOCKED feature submission,
who also provided one of the isolation test specs.

Backpatch to 9.4, because that's as far back as it applies without
conflicts (although the bug goes all the way back).  To that branch also
backpatch Thomas Munro's new NOWAIT test cases, committed in master by
Heikki as commit 9ee16b49f0aac819bd4823d9b94485ef608b34e8 .
src/backend/executor/execMain.c
src/backend/executor/nodeLockRows.c
src/include/executor/executor.h
src/test/isolation/expected/nowait-4.out [new file with mode: 0644]
src/test/isolation/expected/nowait-4_1.out [new file with mode: 0644]
src/test/isolation/expected/nowait-5.out [new file with mode: 0644]
src/test/isolation/isolation_schedule
src/test/isolation/specs/nowait-4.spec [new file with mode: 0644]
src/test/isolation/specs/nowait-5.spec [new file with mode: 0644]