2005-06-18 00:32:51 +02:00
|
|
|
--
|
|
|
|
-- PREPARED TRANSACTIONS (two-phase commit)
|
|
|
|
--
|
|
|
|
-- We can't readily test persistence of prepared xacts within the
|
|
|
|
-- regression script framework, unfortunately. Note that a crash
|
|
|
|
-- isn't really needed ... stopping and starting the postmaster would
|
|
|
|
-- be enough, but we can't even do that here.
|
|
|
|
|
|
|
|
|
|
|
|
-- create a simple table that we'll use in the tests
|
|
|
|
CREATE TABLE pxtest1 (foobar VARCHAR(10));
|
|
|
|
|
|
|
|
INSERT INTO pxtest1 VALUES ('aaa');
|
|
|
|
|
|
|
|
|
|
|
|
-- Test PREPARE TRANSACTION
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
2005-06-18 00:32:51 +02:00
|
|
|
UPDATE pxtest1 SET foobar = 'bbb' WHERE foobar = 'aaa';
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
PREPARE TRANSACTION 'foo1';
|
|
|
|
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
|
|
|
|
-- Test pg_prepared_xacts system view
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
|
|
|
-- Test ROLLBACK PREPARED
|
|
|
|
ROLLBACK PREPARED 'foo1';
|
|
|
|
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
|
|
|
|
|
|
|
-- Test COMMIT PREPARED
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
2005-06-18 00:32:51 +02:00
|
|
|
INSERT INTO pxtest1 VALUES ('ddd');
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
PREPARE TRANSACTION 'foo2';
|
|
|
|
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
|
|
|
|
COMMIT PREPARED 'foo2';
|
|
|
|
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
|
|
|
|
-- Test duplicate gids
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
2005-06-18 00:32:51 +02:00
|
|
|
UPDATE pxtest1 SET foobar = 'eee' WHERE foobar = 'ddd';
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
PREPARE TRANSACTION 'foo3';
|
|
|
|
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
2005-06-18 00:32:51 +02:00
|
|
|
INSERT INTO pxtest1 VALUES ('fff');
|
|
|
|
|
|
|
|
-- This should fail, because the gid foo3 is already in use
|
|
|
|
PREPARE TRANSACTION 'foo3';
|
|
|
|
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
|
|
|
|
ROLLBACK PREPARED 'foo3';
|
|
|
|
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
|
2011-06-21 13:32:11 +02:00
|
|
|
-- Test serialization failure (SSI)
|
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
|
|
|
UPDATE pxtest1 SET foobar = 'eee' WHERE foobar = 'ddd';
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
PREPARE TRANSACTION 'foo4';
|
|
|
|
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
|
|
|
SELECT * FROM pxtest1;
|
|
|
|
|
|
|
|
-- This should fail, because the two transactions have a write-skew anomaly
|
2011-07-07 17:04:37 +02:00
|
|
|
INSERT INTO pxtest1 VALUES ('fff');
|
2011-06-21 13:32:11 +02:00
|
|
|
PREPARE TRANSACTION 'foo5';
|
|
|
|
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
|
|
|
ROLLBACK PREPARED 'foo4';
|
|
|
|
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
2005-06-18 00:32:51 +02:00
|
|
|
-- Clean up
|
|
|
|
DROP TABLE pxtest1;
|
|
|
|
|
|
|
|
-- Test subtransactions
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
2005-06-18 00:32:51 +02:00
|
|
|
CREATE TABLE pxtest2 (a int);
|
|
|
|
INSERT INTO pxtest2 VALUES (1);
|
|
|
|
SAVEPOINT a;
|
|
|
|
INSERT INTO pxtest2 VALUES (2);
|
|
|
|
ROLLBACK TO a;
|
|
|
|
SAVEPOINT b;
|
|
|
|
INSERT INTO pxtest2 VALUES (3);
|
|
|
|
PREPARE TRANSACTION 'regress-one';
|
|
|
|
|
|
|
|
CREATE TABLE pxtest3(fff int);
|
|
|
|
|
|
|
|
-- Test shared invalidation
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
2005-06-18 00:32:51 +02:00
|
|
|
DROP TABLE pxtest3;
|
|
|
|
CREATE TABLE pxtest4 (a int);
|
|
|
|
INSERT INTO pxtest4 VALUES (1);
|
|
|
|
INSERT INTO pxtest4 VALUES (2);
|
|
|
|
DECLARE foo CURSOR FOR SELECT * FROM pxtest4;
|
|
|
|
-- Fetch 1 tuple, keeping the cursor open
|
|
|
|
FETCH 1 FROM foo;
|
|
|
|
PREPARE TRANSACTION 'regress-two';
|
|
|
|
|
|
|
|
-- No such cursor
|
|
|
|
FETCH 1 FROM foo;
|
|
|
|
|
|
|
|
-- Table doesn't exist, the creation hasn't been committed yet
|
|
|
|
SELECT * FROM pxtest2;
|
|
|
|
|
|
|
|
-- There should be two prepared transactions
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
|
|
|
-- pxtest3 should be locked because of the pending DROP
|
2015-10-20 06:37:22 +02:00
|
|
|
begin;
|
2017-03-13 21:46:32 +01:00
|
|
|
lock table pxtest3 in access share mode nowait;
|
2015-10-20 06:37:22 +02:00
|
|
|
rollback;
|
2005-06-18 00:32:51 +02:00
|
|
|
|
|
|
|
-- Disconnect, we will continue testing in a different backend
|
|
|
|
\c -
|
|
|
|
|
|
|
|
-- There should still be two prepared transactions
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
|
|
|
-- pxtest3 should still be locked because of the pending DROP
|
2015-10-20 06:37:22 +02:00
|
|
|
begin;
|
2017-03-13 21:46:32 +01:00
|
|
|
lock table pxtest3 in access share mode nowait;
|
2015-10-20 06:37:22 +02:00
|
|
|
rollback;
|
2005-06-18 00:32:51 +02:00
|
|
|
|
|
|
|
-- Commit table creation
|
|
|
|
COMMIT PREPARED 'regress-one';
|
|
|
|
\d pxtest2
|
|
|
|
SELECT * FROM pxtest2;
|
|
|
|
|
|
|
|
-- There should be one prepared transaction
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
|
|
|
-- Commit table drop
|
|
|
|
COMMIT PREPARED 'regress-two';
|
|
|
|
SELECT * FROM pxtest3;
|
|
|
|
|
|
|
|
-- There should be no prepared transactions
|
|
|
|
SELECT gid FROM pg_prepared_xacts;
|
|
|
|
|
|
|
|
-- Clean up
|
|
|
|
DROP TABLE pxtest2;
|
2009-04-23 02:23:46 +02:00
|
|
|
DROP TABLE pxtest3; -- will still be there if prepared xacts are disabled
|
2005-06-18 00:32:51 +02:00
|
|
|
DROP TABLE pxtest4;
|