database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-18 04:29:09 +03:00
Code Activity

Improve concurrency of foreign key locking

Browse Source 
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE".  These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE".  UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.

Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.

The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid.  Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates.  This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed.  pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.

Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header.  This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.

Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)

With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.

As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.

Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane.  There's probably room for several more tests.

There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it.  Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.

This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
	AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
	1290721684-sup-3951@alvh.no-ip.org
	1294953201-sup-2099@alvh.no-ip.org
	1320343602-sup-2290@alvh.no-ip.org
	1339690386-sup-8927@alvh.no-ip.org
	4FE5FF020200002500048A3D@gw.wicourts.gov
	4FEAB90A0200002500048B7D@gw.wicourts.gov
This commit is contained in:
Alvaro Herrera
2013-01-23 12:04:59 -03:00
parent f925c79b9f
commit 0ac5ad5134
106 changed files with 6019 additions and 1483 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
src/test/isolation/specs/aborted-keyrevoke.spec Normal file
View File

@@ -0,0 +1,31 @@
# When a tuple that has been updated is locked, the locking command
# should traverse the update chain; thus, a DELETE should not be able
# to proceed until the lock has been released.
setup
{
CREATE TABLE foo (
key int PRIMARY KEY,
value int
);
INSERT INTO foo VALUES (1, 1);
}
teardown
{
DROP TABLE foo;
}
session "s1"
setup { BEGIN; }
step "s1s" { SAVEPOINT f; }
step "s1u" { UPDATE foo SET key = 2; } # obtain KEY REVOKE
step "s1r" { ROLLBACK TO f; } # lose KEY REVOKE
step "s1l" { SELECT * FROM foo FOR KEY SHARE; }
step "s1c" { COMMIT; }
session "s2"
setup { BEGIN; }
step "s2l" { SELECT * FROM foo FOR KEY SHARE; }
step "s2c" { COMMIT; }

34
src/test/isolation/specs/delete-abort-savept-2.spec Normal file
View File

@@ -0,0 +1,34 @@
# A funkier version of delete-abort-savept
setup
{
CREATE TABLE foo (
key INT PRIMARY KEY,
value INT
);
INSERT INTO foo VALUES (1, 1);
}
teardown
{
DROP TABLE foo;
}
session "s1"
setup { BEGIN; }
step "s1l" { SELECT * FROM foo FOR KEY SHARE; }
step "s1svp" { SAVEPOINT f; }
step "s1d" { SELECT * FROM foo FOR NO KEY UPDATE; }
step "s1r" { ROLLBACK TO f; }
step "s1c" { COMMIT; }
session "s2"
setup { BEGIN; }
step "s2l" { SELECT * FROM foo FOR UPDATE; }
step "s2l2" { SELECT * FROM foo FOR NO KEY UPDATE; }
step "s2c" { COMMIT; }
permutation "s1l" "s1svp" "s1d" "s1r" "s2l" "s1c" "s2c"
permutation "s1l" "s1svp" "s1d" "s2l" "s1r" "s1c" "s2c"
permutation "s1l" "s1svp" "s1d" "s1r" "s2l2" "s1c" "s2c"
permutation "s1l" "s1svp" "s1d" "s2l2" "s1r" "s1c" "s2c"

29
src/test/isolation/specs/delete-abort-savept.spec Normal file
View File

@@ -0,0 +1,29 @@
# After rolling back a subtransaction that upgraded a lock, the previously
# held lock should still be held.
setup
{
CREATE TABLE foo (
key INT PRIMARY KEY,
value INT
);
INSERT INTO foo VALUES (1, 1);
}
teardown
{
DROP TABLE foo;
}
session "s1"
setup { BEGIN; }
step "s1l" { SELECT * FROM foo FOR KEY SHARE; }
step "s1svp" { SAVEPOINT f; }
step "s1d" { DELETE FROM foo; }
step "s1r" { ROLLBACK TO f; }
step "s1c" { COMMIT; }
session "s2"
setup { BEGIN; }
step "s2l" { SELECT * FROM foo FOR UPDATE; }
step "s2c" { COMMIT; }

23
src/test/isolation/specs/fk-deadlock.spec
View File

@@ -29,26 +29,3 @@ setup { BEGIN; SET deadlock_timeout = '10s'; }
step "s2i" { INSERT INTO child VALUES (2, 1); }
step "s2u" { UPDATE parent SET aux = 'baz'; }
step "s2c" { COMMIT; }
## Most theoretical permutations require that a blocked session execute a
## command, making them impossible in practice.
permutation "s1i" "s1u" "s1c" "s2i" "s2u" "s2c"
permutation "s1i" "s1u" "s2i" "s1c" "s2u" "s2c"
#permutation "s1i" "s1u" "s2i" "s2u" "s1c" "s2c"
#permutation "s1i" "s1u" "s2i" "s2u" "s2c" "s1c"
#permutation "s1i" "s2i" "s1u" "s1c" "s2u" "s2c"
permutation "s1i" "s2i" "s1u" "s2u" "s1c" "s2c"
#permutation "s1i" "s2i" "s1u" "s2u" "s2c" "s1c"
#permutation "s1i" "s2i" "s2u" "s1u" "s1c" "s2c"
permutation "s1i" "s2i" "s2u" "s1u" "s2c" "s1c"
#permutation "s1i" "s2i" "s2u" "s2c" "s1u" "s1c"
#permutation "s2i" "s1i" "s1u" "s1c" "s2u" "s2c"
permutation "s2i" "s1i" "s1u" "s2u" "s1c" "s2c"
#permutation "s2i" "s1i" "s1u" "s2u" "s2c" "s1c"
#permutation "s2i" "s1i" "s2u" "s1u" "s1c" "s2c"
permutation "s2i" "s1i" "s2u" "s1u" "s2c" "s1c"
#permutation "s2i" "s1i" "s2u" "s2c" "s1u" "s1c"
#permutation "s2i" "s2u" "s1i" "s1u" "s1c" "s2c"
#permutation "s2i" "s2u" "s1i" "s1u" "s2c" "s1c"
permutation "s2i" "s2u" "s1i" "s2c" "s1u" "s1c"
#permutation "s2i" "s2u" "s2c" "s1i" "s1u" "s1c"

23
src/test/isolation/specs/fk-deadlock2.spec
View File

@@ -34,26 +34,3 @@ setup { BEGIN; SET deadlock_timeout = '10s'; }
step "s2u1" { UPDATE B SET Col2 = 1 WHERE BID = 2; }
step "s2u2" { UPDATE B SET Col2 = 1 WHERE BID = 2; }
step "s2c" { COMMIT; }
## Many theoretical permutations require that a blocked session execute a
## command, making them impossible in practice.
permutation "s1u1" "s1u2" "s1c" "s2u1" "s2u2" "s2c"
permutation "s1u1" "s1u2" "s2u1" "s1c" "s2u2" "s2c"
#permutation "s1u1" "s1u2" "s2u1" "s2u2" "s1c" "s2c"
#permutation "s1u1" "s1u2" "s2u1" "s2u2" "s2c" "s1c"
#permutation "s1u1" "s2u1" "s1u2" "s1c" "s2u2" "s2c"
permutation "s1u1" "s2u1" "s1u2" "s2u2" "s1c" "s2c"
permutation "s1u1" "s2u1" "s1u2" "s2u2" "s2c" "s1c"
permutation "s1u1" "s2u1" "s2u2" "s1u2" "s1c" "s2c"
permutation "s1u1" "s2u1" "s2u2" "s1u2" "s2c" "s1c"
#permutation "s1u1" "s2u1" "s2u2" "s2c" "s1u2" "s1c"
#permutation "s2u1" "s1u1" "s1u2" "s1c" "s2u2" "s2c"
permutation "s2u1" "s1u1" "s1u2" "s2u2" "s1c" "s2c"
permutation "s2u1" "s1u1" "s1u2" "s2u2" "s2c" "s1c"
permutation "s2u1" "s1u1" "s2u2" "s1u2" "s1c" "s2c"
permutation "s2u1" "s1u1" "s2u2" "s1u2" "s2c" "s1c"
#permutation "s2u1" "s1u1" "s2u2" "s2c" "s1u2" "s1c"
#permutation "s2u1" "s2u2" "s1u1" "s1u2" "s1c" "s2c"
#permutation "s2u1" "s2u2" "s1u1" "s1u2" "s2c" "s1c"
permutation "s2u1" "s2u2" "s1u1" "s2c" "s1u2" "s1c"
#permutation "s2u1" "s2u2" "s2c" "s1u1" "s1u2" "s1c"

38
src/test/isolation/specs/lock-update-delete.spec Normal file
View File

@@ -0,0 +1,38 @@
# If we update a tuple, and then delete (or update that touches the key) it,
# and later somebody tries to come along and traverse that update chain,
# he should get an error when locking the latest version, if the delete
# committed; or succeed, when the deleting transaction rolls back.
setup
{
CREATE TABLE foo (
key int PRIMARY KEY,
value int
);
INSERT INTO foo VALUES (1, 1);
}
teardown
{
DROP TABLE foo;
}
session "s1"
step "s1b" { BEGIN ISOLATION LEVEL REPEATABLE READ; }
step "s1s" { SELECT * FROM foo; } # obtain snapshot
step "s1l" { SELECT * FROM foo FOR KEY SHARE; } # obtain lock
step "s1c" { COMMIT; }
session "s2"
step "s2b" { BEGIN; }
step "s2u" { UPDATE foo SET value = 2 WHERE key = 1; }
step "s2d" { DELETE FROM foo; }
step "s2u2" { UPDATE foo SET key = 2 WHERE key = 1; }
step "s2c" { COMMIT; }
step "s2r" { ROLLBACK; }
permutation "s1b" "s2b" "s1s" "s2u" "s2d" "s1l" "s2c" "s1c"
permutation "s1b" "s2b" "s1s" "s2u" "s2d" "s1l" "s2r" "s1c"
permutation "s1b" "s2b" "s1s" "s2u" "s2u2" "s1l" "s2c" "s1c"
permutation "s1b" "s2b" "s1s" "s2u" "s2u2" "s1l" "s2r" "s1c"

32
src/test/isolation/specs/lock-update-traversal.spec Normal file
View File

@@ -0,0 +1,32 @@
# When a tuple that has been updated is locked, the locking command
# should traverse the update chain; thus, a DELETE should not be able
# to proceed until the lock has been released.
setup
{
CREATE TABLE foo (
key int PRIMARY KEY,
value int
);
INSERT INTO foo VALUES (1, 1);
}
teardown
{
DROP TABLE foo;
}
session "s1"
step "s1b" { BEGIN ISOLATION LEVEL REPEATABLE READ; }
step "s1s" { SELECT * FROM foo; } # obtain snapshot
step "s1l" { SELECT * FROM foo FOR KEY SHARE; } # obtain lock
step "s1c" { COMMIT; }
session "s2"
step "s2b" { BEGIN; }
step "s2u" { UPDATE foo SET value = 2 WHERE key = 1; }
step "s2c" { COMMIT; }
step "s2d" { DELETE FROM foo WHERE key = 1; }
permutation "s1b" "s2b" "s1s" "s2u" "s1l" "s2c" "s2d" "s1c"

35
src/test/isolation/specs/multixact-no-deadlock.spec Normal file
View File

@@ -0,0 +1,35 @@
# If we already hold a lock of a given strength, do not deadlock when
# some other transaction is waiting for a conflicting lock and we try
# to acquire the same lock we already held.
setup
{
CREATE TABLE justthis (
value int
);
INSERT INTO justthis VALUES (1);
}
teardown
{
DROP TABLE justthis;
}
session "s1"
setup { BEGIN; }
step "s1lock" { SELECT * FROM justthis FOR SHARE; }
step "s1svpt" { SAVEPOINT foo; }
step "s1lock2" { SELECT * FROM justthis FOR SHARE; }
step "s1c" { COMMIT; }
session "s2"
setup { BEGIN; }
step "s2lock" { SELECT * FROM justthis FOR SHARE; } # ensure it's a multi
step "s2c" { COMMIT; }
session "s3"
setup { BEGIN; }
step "s3lock" { SELECT * FROM justthis FOR UPDATE; }
step "s3c" { COMMIT; }
permutation "s1lock" "s2lock" "s1svpt" "s3lock" "s1lock2" "s2c" "s1c" "s3c"