2000-01-09 04:48:39 +01:00
|
|
|
--
|
|
|
|
-- TRANSACTIONS
|
|
|
|
--
|
|
|
|
BEGIN;
|
2010-11-23 21:27:50 +01:00
|
|
|
SELECT *
|
1997-04-29 16:23:51 +02:00
|
|
|
INTO TABLE xacttest
|
|
|
|
FROM aggtest;
|
2000-01-09 04:48:39 +01:00
|
|
|
INSERT INTO xacttest (a, b) VALUES (777, 777.777);
|
|
|
|
END;
|
|
|
|
-- should retrieve one value--
|
|
|
|
SELECT a FROM xacttest WHERE a > 100;
|
|
|
|
a
|
|
|
|
-----
|
|
|
|
777
|
1997-04-29 16:23:51 +02:00
|
|
|
(1 row)
|
|
|
|
|
2000-01-09 04:48:39 +01:00
|
|
|
BEGIN;
|
|
|
|
CREATE TABLE disappear (a int4);
|
|
|
|
DELETE FROM aggtest;
|
|
|
|
-- should be empty
|
|
|
|
SELECT * FROM aggtest;
|
|
|
|
a | b
|
|
|
|
---+---
|
1997-04-29 16:23:51 +02:00
|
|
|
(0 rows)
|
|
|
|
|
2000-01-09 04:48:39 +01:00
|
|
|
ABORT;
|
2010-11-23 21:27:50 +01:00
|
|
|
-- should not exist
|
2000-01-09 04:48:39 +01:00
|
|
|
SELECT oid FROM pg_class WHERE relname = 'disappear';
|
|
|
|
oid
|
|
|
|
-----
|
1997-04-29 16:23:51 +02:00
|
|
|
(0 rows)
|
|
|
|
|
2010-11-23 21:27:50 +01:00
|
|
|
-- should have members again
|
2000-01-09 04:48:39 +01:00
|
|
|
SELECT * FROM aggtest;
|
|
|
|
a | b
|
|
|
|
-----+---------
|
|
|
|
56 | 7.8
|
|
|
|
100 | 99.097
|
|
|
|
0 | 0.09561
|
|
|
|
42 | 324.78
|
1997-04-29 16:23:51 +02:00
|
|
|
(4 rows)
|
|
|
|
|
2003-01-10 23:03:30 +01:00
|
|
|
-- Read-only tests
|
|
|
|
CREATE TABLE writetest (a int);
|
|
|
|
CREATE TEMPORARY TABLE temptest (a int);
|
2011-01-23 02:51:32 +01:00
|
|
|
BEGIN;
|
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
|
|
|
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, READ ONLY, DEFERRABLE; -- ok
|
2011-01-23 02:51:32 +01:00
|
|
|
SELECT * FROM writetest; -- ok
|
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
SET TRANSACTION READ WRITE; --fail
|
|
|
|
ERROR: transaction read-write mode must be set before any query
|
|
|
|
COMMIT;
|
|
|
|
BEGIN;
|
|
|
|
SET TRANSACTION READ ONLY; -- ok
|
|
|
|
SET TRANSACTION READ WRITE; -- ok
|
|
|
|
SET TRANSACTION READ ONLY; -- ok
|
|
|
|
SELECT * FROM writetest; -- ok
|
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
SAVEPOINT x;
|
|
|
|
SET TRANSACTION READ ONLY; -- ok
|
|
|
|
SELECT * FROM writetest; -- ok
|
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
SET TRANSACTION READ ONLY; -- ok
|
|
|
|
SET TRANSACTION READ WRITE; --fail
|
|
|
|
ERROR: cannot set transaction read-write mode inside a read-only transaction
|
|
|
|
COMMIT;
|
|
|
|
BEGIN;
|
|
|
|
SET TRANSACTION READ WRITE; -- ok
|
|
|
|
SAVEPOINT x;
|
|
|
|
SET TRANSACTION READ WRITE; -- ok
|
|
|
|
SET TRANSACTION READ ONLY; -- ok
|
|
|
|
SELECT * FROM writetest; -- ok
|
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
SET TRANSACTION READ ONLY; -- ok
|
|
|
|
SET TRANSACTION READ WRITE; --fail
|
|
|
|
ERROR: cannot set transaction read-write mode inside a read-only transaction
|
|
|
|
COMMIT;
|
|
|
|
BEGIN;
|
|
|
|
SET TRANSACTION READ WRITE; -- ok
|
|
|
|
SAVEPOINT x;
|
|
|
|
SET TRANSACTION READ ONLY; -- ok
|
|
|
|
SELECT * FROM writetest; -- ok
|
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
ROLLBACK TO SAVEPOINT x;
|
|
|
|
SHOW transaction_read_only; -- off
|
|
|
|
transaction_read_only
|
|
|
|
-----------------------
|
|
|
|
off
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SAVEPOINT y;
|
|
|
|
SET TRANSACTION READ ONLY; -- ok
|
|
|
|
SELECT * FROM writetest; -- ok
|
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
RELEASE SAVEPOINT y;
|
|
|
|
SHOW transaction_read_only; -- off
|
|
|
|
transaction_read_only
|
|
|
|
-----------------------
|
|
|
|
off
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
COMMIT;
|
2003-01-10 23:03:30 +01:00
|
|
|
SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;
|
|
|
|
DROP TABLE writetest; -- fail
|
2010-02-20 22:24:02 +01:00
|
|
|
ERROR: cannot execute DROP TABLE in a read-only transaction
|
2003-01-10 23:03:30 +01:00
|
|
|
INSERT INTO writetest VALUES (1); -- fail
|
2010-02-20 22:24:02 +01:00
|
|
|
ERROR: cannot execute INSERT in a read-only transaction
|
2003-01-10 23:03:30 +01:00
|
|
|
SELECT * FROM writetest; -- ok
|
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
DELETE FROM temptest; -- ok
|
2005-04-07 03:51:41 +02:00
|
|
|
UPDATE temptest SET a = 0 FROM writetest WHERE temptest.a = 1 AND writetest.a = temptest.a; -- ok
|
2003-01-10 23:03:30 +01:00
|
|
|
PREPARE test AS UPDATE writetest SET a = 0; -- ok
|
|
|
|
EXECUTE test; -- fail
|
2010-02-20 22:24:02 +01:00
|
|
|
ERROR: cannot execute UPDATE in a read-only transaction
|
2003-01-10 23:03:30 +01:00
|
|
|
SELECT * FROM writetest, temptest; -- ok
|
|
|
|
a | a
|
|
|
|
---+---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
CREATE TABLE test AS SELECT * FROM writetest; -- fail
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
ERROR: cannot execute CREATE TABLE AS in a read-only transaction
|
2003-01-10 23:03:30 +01:00
|
|
|
START TRANSACTION READ WRITE;
|
|
|
|
DROP TABLE writetest; -- ok
|
|
|
|
COMMIT;
|
2004-07-01 02:52:04 +02:00
|
|
|
-- Subtransactions, basic tests
|
|
|
|
-- create & drop tables
|
|
|
|
SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
CREATE TABLE trans_foobar (a int);
|
2004-07-01 02:52:04 +02:00
|
|
|
BEGIN;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
CREATE TABLE trans_foo (a int);
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT one;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
DROP TABLE trans_foo;
|
|
|
|
CREATE TABLE trans_bar (a int);
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT one;
|
|
|
|
RELEASE SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT two;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
CREATE TABLE trans_baz (a int);
|
2004-08-12 21:12:21 +02:00
|
|
|
RELEASE SAVEPOINT two;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
drop TABLE trans_foobar;
|
|
|
|
CREATE TABLE trans_barbaz (a int);
|
2004-07-01 02:52:04 +02:00
|
|
|
COMMIT;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
-- should exist: trans_barbaz, trans_baz, trans_foo
|
|
|
|
SELECT * FROM trans_foo; -- should be empty
|
2004-07-01 02:52:04 +02:00
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
SELECT * FROM trans_bar; -- shouldn't exist
|
|
|
|
ERROR: relation "trans_bar" does not exist
|
|
|
|
LINE 1: SELECT * FROM trans_bar;
|
2008-09-01 22:42:46 +02:00
|
|
|
^
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
SELECT * FROM trans_barbaz; -- should be empty
|
2004-07-01 02:52:04 +02:00
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
SELECT * FROM trans_baz; -- should be empty
|
2004-07-01 02:52:04 +02:00
|
|
|
a
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
|
|
|
-- inserts
|
|
|
|
BEGIN;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
INSERT INTO trans_foo VALUES (1);
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT one;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
INSERT into trans_bar VALUES (1);
|
|
|
|
ERROR: relation "trans_bar" does not exist
|
|
|
|
LINE 1: INSERT into trans_bar VALUES (1);
|
2008-09-01 22:42:46 +02:00
|
|
|
^
|
2004-07-27 07:11:48 +02:00
|
|
|
ROLLBACK TO one;
|
2004-08-12 21:12:21 +02:00
|
|
|
RELEASE SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT two;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
INSERT into trans_barbaz VALUES (1);
|
2004-07-27 07:11:48 +02:00
|
|
|
RELEASE two;
|
|
|
|
SAVEPOINT three;
|
|
|
|
SAVEPOINT four;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
INSERT INTO trans_foo VALUES (2);
|
2004-08-12 21:12:21 +02:00
|
|
|
RELEASE SAVEPOINT four;
|
|
|
|
ROLLBACK TO SAVEPOINT three;
|
|
|
|
RELEASE SAVEPOINT three;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
INSERT INTO trans_foo VALUES (3);
|
2004-07-01 02:52:04 +02:00
|
|
|
COMMIT;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
SELECT * FROM trans_foo; -- should have 1 and 3
|
2004-07-01 02:52:04 +02:00
|
|
|
a
|
|
|
|
---
|
|
|
|
1
|
|
|
|
3
|
|
|
|
(2 rows)
|
|
|
|
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
SELECT * FROM trans_barbaz; -- should have 1
|
2004-07-01 02:52:04 +02:00
|
|
|
a
|
|
|
|
---
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
2004-07-27 07:11:48 +02:00
|
|
|
-- test whole-tree commit
|
2004-07-01 22:11:03 +02:00
|
|
|
BEGIN;
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT one;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
SELECT trans_foo;
|
|
|
|
ERROR: column "trans_foo" does not exist
|
|
|
|
LINE 1: SELECT trans_foo;
|
2006-03-14 23:48:25 +01:00
|
|
|
^
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT one;
|
|
|
|
RELEASE SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT two;
|
|
|
|
CREATE TABLE savepoints (a int);
|
|
|
|
SAVEPOINT three;
|
|
|
|
INSERT INTO savepoints VALUES (1);
|
|
|
|
SAVEPOINT four;
|
|
|
|
INSERT INTO savepoints VALUES (2);
|
|
|
|
SAVEPOINT five;
|
|
|
|
INSERT INTO savepoints VALUES (3);
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT five;
|
2004-07-01 22:11:03 +02:00
|
|
|
COMMIT;
|
2004-07-27 07:11:48 +02:00
|
|
|
COMMIT; -- should not be in a transaction block
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
SELECT * FROM savepoints;
|
|
|
|
a
|
|
|
|
---
|
|
|
|
1
|
|
|
|
2
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- test whole-tree rollback
|
|
|
|
BEGIN;
|
|
|
|
SAVEPOINT one;
|
|
|
|
DELETE FROM savepoints WHERE a=1;
|
2004-08-12 21:12:21 +02:00
|
|
|
RELEASE SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT two;
|
|
|
|
DELETE FROM savepoints WHERE a=1;
|
|
|
|
SAVEPOINT three;
|
|
|
|
DELETE FROM savepoints WHERE a=2;
|
|
|
|
ROLLBACK;
|
|
|
|
COMMIT; -- should not be in a transaction block
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
SELECT * FROM savepoints;
|
|
|
|
a
|
|
|
|
---
|
|
|
|
1
|
|
|
|
2
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- test whole-tree commit on an aborted subtransaction
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO savepoints VALUES (4);
|
|
|
|
SAVEPOINT one;
|
|
|
|
INSERT INTO savepoints VALUES (5);
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
SELECT trans_foo;
|
|
|
|
ERROR: column "trans_foo" does not exist
|
|
|
|
LINE 1: SELECT trans_foo;
|
2006-03-14 23:48:25 +01:00
|
|
|
^
|
2004-07-27 07:11:48 +02:00
|
|
|
COMMIT;
|
|
|
|
SELECT * FROM savepoints;
|
|
|
|
a
|
|
|
|
---
|
|
|
|
1
|
|
|
|
2
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO savepoints VALUES (6);
|
|
|
|
SAVEPOINT one;
|
|
|
|
INSERT INTO savepoints VALUES (7);
|
2004-08-12 21:12:21 +02:00
|
|
|
RELEASE SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
INSERT INTO savepoints VALUES (8);
|
|
|
|
COMMIT;
|
|
|
|
-- rows 6 and 8 should have been created by the same xact
|
|
|
|
SELECT a.xmin = b.xmin FROM savepoints a, savepoints b WHERE a.a=6 AND b.a=8;
|
2004-07-01 22:11:03 +02:00
|
|
|
?column?
|
|
|
|
----------
|
2004-07-27 07:11:48 +02:00
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- rows 6 and 7 should have been created by different xacts
|
|
|
|
SELECT a.xmin = b.xmin FROM savepoints a, savepoints b WHERE a.a=6 AND b.a=7;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
f
|
2004-07-01 22:11:03 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
BEGIN;
|
2004-07-27 07:11:48 +02:00
|
|
|
INSERT INTO savepoints VALUES (9);
|
|
|
|
SAVEPOINT one;
|
|
|
|
INSERT INTO savepoints VALUES (10);
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
INSERT INTO savepoints VALUES (11);
|
|
|
|
COMMIT;
|
|
|
|
SELECT a FROM savepoints WHERE a in (9, 10, 11);
|
|
|
|
a
|
|
|
|
----
|
|
|
|
9
|
|
|
|
11
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- rows 9 and 11 should have been created by different xacts
|
|
|
|
SELECT a.xmin = b.xmin FROM savepoints a, savepoints b WHERE a.a=9 AND b.a=11;
|
2004-07-01 22:11:03 +02:00
|
|
|
?column?
|
|
|
|
----------
|
2004-07-27 07:11:48 +02:00
|
|
|
f
|
2004-07-01 22:11:03 +02:00
|
|
|
(1 row)
|
|
|
|
|
2004-07-27 07:11:48 +02:00
|
|
|
BEGIN;
|
|
|
|
INSERT INTO savepoints VALUES (12);
|
|
|
|
SAVEPOINT one;
|
|
|
|
INSERT INTO savepoints VALUES (13);
|
|
|
|
SAVEPOINT two;
|
|
|
|
INSERT INTO savepoints VALUES (14);
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
INSERT INTO savepoints VALUES (15);
|
|
|
|
SAVEPOINT two;
|
|
|
|
INSERT INTO savepoints VALUES (16);
|
|
|
|
SAVEPOINT three;
|
|
|
|
INSERT INTO savepoints VALUES (17);
|
|
|
|
COMMIT;
|
|
|
|
SELECT a FROM savepoints WHERE a BETWEEN 12 AND 17;
|
|
|
|
a
|
|
|
|
----
|
|
|
|
12
|
|
|
|
15
|
|
|
|
16
|
|
|
|
17
|
|
|
|
(4 rows)
|
|
|
|
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO savepoints VALUES (18);
|
|
|
|
SAVEPOINT one;
|
|
|
|
INSERT INTO savepoints VALUES (19);
|
|
|
|
SAVEPOINT two;
|
|
|
|
INSERT INTO savepoints VALUES (20);
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
INSERT INTO savepoints VALUES (21);
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
INSERT INTO savepoints VALUES (22);
|
|
|
|
COMMIT;
|
|
|
|
SELECT a FROM savepoints WHERE a BETWEEN 18 AND 22;
|
|
|
|
a
|
|
|
|
----
|
|
|
|
18
|
|
|
|
22
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
DROP TABLE savepoints;
|
|
|
|
-- only in a transaction block:
|
|
|
|
SAVEPOINT one;
|
Wording cleanup for error messages. Also change can't -> cannot.
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 20:10:30 +01:00
|
|
|
ERROR: SAVEPOINT can only be used in transaction blocks
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT one;
|
Wording cleanup for error messages. Also change can't -> cannot.
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 20:10:30 +01:00
|
|
|
ERROR: ROLLBACK TO SAVEPOINT can only be used in transaction blocks
|
2004-08-12 21:12:21 +02:00
|
|
|
RELEASE SAVEPOINT one;
|
Wording cleanup for error messages. Also change can't -> cannot.
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 20:10:30 +01:00
|
|
|
ERROR: RELEASE SAVEPOINT can only be used in transaction blocks
|
2004-07-27 07:11:48 +02:00
|
|
|
-- Only "rollback to" allowed in aborted state
|
|
|
|
BEGIN;
|
|
|
|
SAVEPOINT one;
|
|
|
|
SELECT 0/0;
|
2004-07-01 22:11:03 +02:00
|
|
|
ERROR: division by zero
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT two; -- ignored till the end of ...
|
2004-07-01 22:11:03 +02:00
|
|
|
ERROR: current transaction is aborted, commands ignored until end of transaction block
|
2004-08-12 21:12:21 +02:00
|
|
|
RELEASE SAVEPOINT one; -- ignored till the end of ...
|
2004-07-01 22:11:03 +02:00
|
|
|
ERROR: current transaction is aborted, commands ignored until end of transaction block
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT one;
|
2004-07-27 07:11:48 +02:00
|
|
|
SELECT 1;
|
2004-07-01 22:11:03 +02:00
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
COMMIT;
|
|
|
|
SELECT 1; -- this should work
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
2004-07-17 05:32:14 +02:00
|
|
|
-- check non-transactional behavior of cursors
|
|
|
|
BEGIN;
|
2007-06-09 19:24:46 +02:00
|
|
|
DECLARE c CURSOR FOR SELECT unique2 FROM tenk1 ORDER BY unique2;
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT one;
|
2004-07-17 05:32:14 +02:00
|
|
|
FETCH 10 FROM c;
|
|
|
|
unique2
|
|
|
|
---------
|
|
|
|
0
|
|
|
|
1
|
|
|
|
2
|
|
|
|
3
|
|
|
|
4
|
|
|
|
5
|
|
|
|
6
|
|
|
|
7
|
|
|
|
8
|
|
|
|
9
|
|
|
|
(10 rows)
|
|
|
|
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT one;
|
2004-07-17 05:32:14 +02:00
|
|
|
FETCH 10 FROM c;
|
|
|
|
unique2
|
|
|
|
---------
|
|
|
|
10
|
|
|
|
11
|
|
|
|
12
|
|
|
|
13
|
|
|
|
14
|
|
|
|
15
|
|
|
|
16
|
|
|
|
17
|
|
|
|
18
|
|
|
|
19
|
|
|
|
(10 rows)
|
|
|
|
|
2004-08-12 21:12:21 +02:00
|
|
|
RELEASE SAVEPOINT one;
|
2004-07-17 05:32:14 +02:00
|
|
|
FETCH 10 FROM c;
|
|
|
|
unique2
|
|
|
|
---------
|
|
|
|
20
|
|
|
|
21
|
|
|
|
22
|
|
|
|
23
|
|
|
|
24
|
|
|
|
25
|
|
|
|
26
|
|
|
|
27
|
|
|
|
28
|
|
|
|
29
|
|
|
|
(10 rows)
|
|
|
|
|
|
|
|
CLOSE c;
|
2007-06-09 19:24:46 +02:00
|
|
|
DECLARE c CURSOR FOR SELECT unique2/0 FROM tenk1 ORDER BY unique2;
|
2004-07-27 07:11:48 +02:00
|
|
|
SAVEPOINT two;
|
2004-07-17 05:32:14 +02:00
|
|
|
FETCH 10 FROM c;
|
|
|
|
ERROR: division by zero
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT two;
|
2004-07-17 05:32:14 +02:00
|
|
|
-- c is now dead to the world ...
|
|
|
|
FETCH 10 FROM c;
|
|
|
|
ERROR: portal "c" cannot be run
|
2004-08-12 21:12:21 +02:00
|
|
|
ROLLBACK TO SAVEPOINT two;
|
|
|
|
RELEASE SAVEPOINT two;
|
2004-07-17 05:32:14 +02:00
|
|
|
FETCH 10 FROM c;
|
|
|
|
ERROR: portal "c" cannot be run
|
|
|
|
COMMIT;
|
2004-09-13 22:10:13 +02:00
|
|
|
--
|
|
|
|
-- Check that "stable" functions are really stable. They should not be
|
|
|
|
-- able to see the partial results of the calling query. (Ideally we would
|
|
|
|
-- also check that they don't see commits of concurrent transactions, but
|
|
|
|
-- that's a mite hard to do within the limitations of pg_regress.)
|
|
|
|
--
|
|
|
|
select * from xacttest;
|
|
|
|
a | b
|
|
|
|
-----+---------
|
|
|
|
56 | 7.8
|
|
|
|
100 | 99.097
|
|
|
|
0 | 0.09561
|
|
|
|
42 | 324.78
|
|
|
|
777 | 777.777
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
create or replace function max_xacttest() returns smallint language sql as
|
|
|
|
'select max(a) from xacttest' stable;
|
|
|
|
begin;
|
|
|
|
update xacttest set a = max_xacttest() + 10 where a > 0;
|
|
|
|
select * from xacttest;
|
|
|
|
a | b
|
|
|
|
-----+---------
|
|
|
|
0 | 0.09561
|
|
|
|
787 | 7.8
|
|
|
|
787 | 99.097
|
|
|
|
787 | 324.78
|
|
|
|
787 | 777.777
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
rollback;
|
|
|
|
-- But a volatile function can see the partial results of the calling query
|
|
|
|
create or replace function max_xacttest() returns smallint language sql as
|
|
|
|
'select max(a) from xacttest' volatile;
|
|
|
|
begin;
|
|
|
|
update xacttest set a = max_xacttest() + 10 where a > 0;
|
|
|
|
select * from xacttest;
|
|
|
|
a | b
|
|
|
|
-----+---------
|
|
|
|
0 | 0.09561
|
|
|
|
787 | 7.8
|
|
|
|
797 | 99.097
|
|
|
|
807 | 324.78
|
|
|
|
817 | 777.777
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
rollback;
|
|
|
|
-- Now the same test with plpgsql (since it depends on SPI which is different)
|
|
|
|
create or replace function max_xacttest() returns smallint language plpgsql as
|
|
|
|
'begin return max(a) from xacttest; end' stable;
|
|
|
|
begin;
|
|
|
|
update xacttest set a = max_xacttest() + 10 where a > 0;
|
|
|
|
select * from xacttest;
|
|
|
|
a | b
|
|
|
|
-----+---------
|
|
|
|
0 | 0.09561
|
|
|
|
787 | 7.8
|
|
|
|
787 | 99.097
|
|
|
|
787 | 324.78
|
|
|
|
787 | 777.777
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
rollback;
|
|
|
|
create or replace function max_xacttest() returns smallint language plpgsql as
|
|
|
|
'begin return max(a) from xacttest; end' volatile;
|
|
|
|
begin;
|
|
|
|
update xacttest set a = max_xacttest() + 10 where a > 0;
|
|
|
|
select * from xacttest;
|
|
|
|
a | b
|
|
|
|
-----+---------
|
|
|
|
0 | 0.09561
|
|
|
|
787 | 7.8
|
|
|
|
797 | 99.097
|
|
|
|
807 | 324.78
|
|
|
|
817 | 777.777
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
rollback;
|
2004-09-06 19:56:33 +02:00
|
|
|
-- test case for problems with dropping an open relation during abort
|
|
|
|
BEGIN;
|
|
|
|
savepoint x;
|
|
|
|
CREATE TABLE koju (a INT UNIQUE);
|
|
|
|
INSERT INTO koju VALUES (1);
|
|
|
|
INSERT INTO koju VALUES (1);
|
2007-06-04 00:16:03 +02:00
|
|
|
ERROR: duplicate key value violates unique constraint "koju_a_key"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (a)=(1) already exists.
|
2004-09-06 19:56:33 +02:00
|
|
|
rollback to x;
|
|
|
|
CREATE TABLE koju (a INT UNIQUE);
|
|
|
|
INSERT INTO koju VALUES (1);
|
|
|
|
INSERT INTO koju VALUES (1);
|
2007-06-04 00:16:03 +02:00
|
|
|
ERROR: duplicate key value violates unique constraint "koju_a_key"
|
2009-08-01 21:59:41 +02:00
|
|
|
DETAIL: Key (a)=(1) already exists.
|
2004-09-06 19:56:33 +02:00
|
|
|
ROLLBACK;
|
Clean up duplicate table and function names in regression tests.
Many of the objects we create during the regression tests are put in the
public schema, so that using the same names in different regression tests
creates a hazard of test failures if any two such scripts run concurrently.
This patch cleans up a bunch of latent hazards of that sort, as well as two
live hazards.
The current situation in this regard is far worse than it was a year or two
back, because practically all of the partitioning-related test cases have
reused table names with enthusiasm. I despaired of cleaning up that mess
within the five most-affected tests (create_table, alter_table, insert,
update, inherit); fortunately those don't run concurrently.
Other than partitioning problems, most of the issues boil down to using
names like "foo", "bar", "tmp", etc, without thought for the fact that
other test scripts might use similar names concurrently. I've made an
effort to make all such names more specific.
One of the live hazards was that commit 7421f4b8 caused with.sql to
create a table named "test", conflicting with a similarly-named table
in alter_table.sql; this was exposed in the buildfarm recently.
The other one was that join.sql and transactions.sql both create tables
named "foo" and "bar"; but join.sql's uses of those names date back
only to December or so.
Since commit 7421f4b8 was back-patched to v10, back-patch a minimal
fix for that problem. The rest of this is just future-proofing.
Discussion: https://postgr.es/m/4627.1521070268@sss.pgh.pa.us
2018-03-15 22:08:51 +01:00
|
|
|
DROP TABLE trans_foo;
|
|
|
|
DROP TABLE trans_baz;
|
|
|
|
DROP TABLE trans_barbaz;
|
2014-02-07 01:37:58 +01:00
|
|
|
-- test case for problems with revalidating an open relation during abort
|
|
|
|
create function inverse(int) returns float8 as
|
|
|
|
$$
|
|
|
|
begin
|
|
|
|
analyze revalidate_bug;
|
|
|
|
return 1::float8/$1;
|
|
|
|
exception
|
|
|
|
when division_by_zero then return 0;
|
|
|
|
end$$ language plpgsql volatile;
|
|
|
|
create table revalidate_bug (c float8 unique);
|
|
|
|
insert into revalidate_bug values (1);
|
|
|
|
insert into revalidate_bug values (inverse(0));
|
|
|
|
drop table revalidate_bug;
|
|
|
|
drop function inverse(int);
|
2005-01-27 02:32:00 +01:00
|
|
|
-- verify that cursors created during an aborted subtransaction are
|
|
|
|
-- closed, but that we do not rollback the effect of any FETCHs
|
|
|
|
-- performed in the aborted subtransaction
|
|
|
|
begin;
|
|
|
|
savepoint x;
|
|
|
|
create table abc (a int);
|
|
|
|
insert into abc values (5);
|
|
|
|
insert into abc values (10);
|
|
|
|
declare foo cursor for select * from abc;
|
|
|
|
fetch from foo;
|
|
|
|
a
|
|
|
|
---
|
|
|
|
5
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
rollback to x;
|
|
|
|
-- should fail
|
|
|
|
fetch from foo;
|
|
|
|
ERROR: cursor "foo" does not exist
|
|
|
|
commit;
|
|
|
|
begin;
|
|
|
|
create table abc (a int);
|
|
|
|
insert into abc values (5);
|
|
|
|
insert into abc values (10);
|
|
|
|
insert into abc values (15);
|
|
|
|
declare foo cursor for select * from abc;
|
|
|
|
fetch from foo;
|
|
|
|
a
|
|
|
|
---
|
|
|
|
5
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
savepoint x;
|
|
|
|
fetch from foo;
|
|
|
|
a
|
|
|
|
----
|
|
|
|
10
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
rollback to x;
|
|
|
|
fetch from foo;
|
|
|
|
a
|
|
|
|
----
|
|
|
|
15
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
abort;
|
Fix subtransaction cleanup after an outer-subtransaction portal fails.
Formerly, we treated only portals created in the current subtransaction as
having failed during subtransaction abort. However, if the error occurred
while running a portal created in an outer subtransaction (ie, a cursor
declared before the last savepoint), that has to be considered broken too.
To allow reliable detection of which ones those are, add a bookkeeping
field to struct Portal that tracks the innermost subtransaction in which
each portal has actually been executed. (Without this, we'd end up
failing portals containing functions that had called the subtransaction,
thereby breaking plpgsql exception blocks completely.)
In addition, when we fail an outer-subtransaction Portal, transfer its
resources into the subtransaction's resource owner, so that they're
released early in cleanup of the subxact. This fixes a problem reported by
Jim Nasby in which a function executed in an outer-subtransaction cursor
could cause an Assert failure or crash by referencing a relation created
within the inner subtransaction.
The proximate cause of the Assert failure is that AtEOSubXact_RelationCache
assumed it could blow away a relcache entry without first checking that the
entry had zero refcount. That was a bad idea on its own terms, so add such
a check there, and to the similar coding in AtEOXact_RelationCache. This
provides an independent safety measure in case there are still ways to
provoke the situation despite the Portal-level changes.
This has been broken since subtransactions were invented, so back-patch
to all supported branches.
Tom Lane and Michael Paquier
2015-09-04 19:36:49 +02:00
|
|
|
-- Test for proper cleanup after a failure in a cursor portal
|
|
|
|
-- that was created in an outer subtransaction
|
|
|
|
CREATE FUNCTION invert(x float8) RETURNS float8 LANGUAGE plpgsql AS
|
|
|
|
$$ begin return 1/x; end $$;
|
|
|
|
CREATE FUNCTION create_temp_tab() RETURNS text
|
|
|
|
LANGUAGE plpgsql AS $$
|
|
|
|
BEGIN
|
|
|
|
CREATE TEMP TABLE new_table (f1 float8);
|
|
|
|
-- case of interest is that we fail while holding an open
|
|
|
|
-- relcache reference to new_table
|
|
|
|
INSERT INTO new_table SELECT invert(0.0);
|
|
|
|
RETURN 'foo';
|
|
|
|
END $$;
|
|
|
|
BEGIN;
|
|
|
|
DECLARE ok CURSOR FOR SELECT * FROM int8_tbl;
|
|
|
|
DECLARE ctt CURSOR FOR SELECT create_temp_tab();
|
|
|
|
FETCH ok;
|
|
|
|
q1 | q2
|
|
|
|
-----+-----
|
|
|
|
123 | 456
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SAVEPOINT s1;
|
|
|
|
FETCH ok; -- should work
|
|
|
|
q1 | q2
|
|
|
|
-----+------------------
|
|
|
|
123 | 4567890123456789
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
FETCH ctt; -- error occurs here
|
|
|
|
ERROR: division by zero
|
|
|
|
CONTEXT: PL/pgSQL function invert(double precision) line 1 at RETURN
|
|
|
|
SQL statement "INSERT INTO new_table SELECT invert(0.0)"
|
|
|
|
PL/pgSQL function create_temp_tab() line 6 at SQL statement
|
|
|
|
ROLLBACK TO s1;
|
|
|
|
FETCH ok; -- should work
|
|
|
|
q1 | q2
|
|
|
|
------------------+-----
|
|
|
|
4567890123456789 | 123
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
FETCH ctt; -- must be rejected
|
|
|
|
ERROR: portal "ctt" cannot be run
|
|
|
|
COMMIT;
|
|
|
|
DROP FUNCTION create_temp_tab();
|
|
|
|
DROP FUNCTION invert(x float8);
|
Fix handling of savepoint commands within multi-statement Query strings.
Issuing a savepoint-related command in a Query message that contains
multiple SQL statements led to a FATAL exit with a complaint about
"unexpected state STARTED". This is a shortcoming of commit 4f896dac1,
which attempted to prevent such misbehaviors in multi-statement strings;
its quick hack of marking the individual statements as "not top-level"
does the wrong thing in this case, and isn't a very accurate description
of the situation anyway.
To fix, let's introduce into xact.c an explicit model of what happens for
multi-statement Query strings. This is an "implicit transaction block
in progress" state, which for many purposes works like the normal
TBLOCK_INPROGRESS state --- in particular, IsTransactionBlock returns true,
causing the desired result that PreventTransactionChain will throw error.
But in case of error abort it works like TBLOCK_STARTED, allowing the
transaction to be cancelled without need for an explicit ROLLBACK command.
Commit 4f896dac1 is reverted in toto, so that we go back to treating the
individual statements as "top level". We could have left it as-is, but
this allows sharpening the error message for PreventTransactionChain
calls inside functions.
Except for getting a normal error instead of a FATAL exit for savepoint
commands, this patch should result in no user-visible behavioral change
(other than that one error message rewording). There are some things
we might want to do in the line of changing the appearance or wording of
error and warning messages around this behavior, which would be much
simpler to do now that it's an explicitly modeled state. But I haven't
done them here.
Although this fixes a long-standing bug, no backpatch. The consequences
of the bug don't seem severe enough to justify the risk that this commit
itself creates some new issue.
Patch by me, but it owes something to previous investigation by
Takayuki Tsunakawa, who also reported the bug in the first place.
Also thanks to Michael Paquier for reviewing.
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F6BE40D@G01JPEXMBYT05
2017-09-07 15:49:55 +02:00
|
|
|
-- Test assorted behaviors around the implicit transaction block created
|
|
|
|
-- when multiple SQL commands are sent in a single Query message. These
|
|
|
|
-- tests rely on the fact that psql will not break SQL commands apart at a
|
|
|
|
-- backslash-quoted semicolon, but will send them as one Query.
|
|
|
|
create temp table i_table (f1 int);
|
|
|
|
-- psql will show only the last result in a multi-statement Query
|
|
|
|
SELECT 1\; SELECT 2\; SELECT 3;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
3
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- this implicitly commits:
|
|
|
|
insert into i_table values(1)\; select * from i_table;
|
|
|
|
f1
|
|
|
|
----
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- 1/0 error will cause rolling back the whole implicit transaction
|
|
|
|
insert into i_table values(2)\; select * from i_table\; select 1/0;
|
|
|
|
ERROR: division by zero
|
|
|
|
select * from i_table;
|
|
|
|
f1
|
|
|
|
----
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
rollback; -- we are not in a transaction at this point
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
-- can use regular begin/commit/rollback within a single Query
|
|
|
|
begin\; insert into i_table values(3)\; commit;
|
|
|
|
rollback; -- we are not in a transaction at this point
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
begin\; insert into i_table values(4)\; rollback;
|
|
|
|
rollback; -- we are not in a transaction at this point
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
-- begin converts implicit transaction into a regular one that
|
|
|
|
-- can extend past the end of the Query
|
|
|
|
select 1\; begin\; insert into i_table values(5);
|
|
|
|
commit;
|
|
|
|
select 1\; begin\; insert into i_table values(6);
|
|
|
|
rollback;
|
|
|
|
-- commit in implicit-transaction state commits but issues a warning.
|
|
|
|
insert into i_table values(7)\; commit\; insert into i_table values(8)\; select 1/0;
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
ERROR: division by zero
|
|
|
|
-- similarly, rollback aborts but issues a warning.
|
|
|
|
insert into i_table values(9)\; rollback\; select 2;
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select * from i_table;
|
|
|
|
f1
|
|
|
|
----
|
|
|
|
1
|
|
|
|
3
|
|
|
|
5
|
|
|
|
7
|
|
|
|
(4 rows)
|
|
|
|
|
|
|
|
rollback; -- we are not in a transaction at this point
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
-- implicit transaction block is still a transaction block, for e.g. VACUUM
|
|
|
|
SELECT 1\; VACUUM;
|
|
|
|
ERROR: VACUUM cannot run inside a transaction block
|
|
|
|
SELECT 1\; COMMIT\; VACUUM;
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
ERROR: VACUUM cannot run inside a transaction block
|
|
|
|
-- we disallow savepoint-related commands in implicit-transaction state
|
|
|
|
SELECT 1\; SAVEPOINT sp;
|
|
|
|
ERROR: SAVEPOINT can only be used in transaction blocks
|
|
|
|
SELECT 1\; COMMIT\; SAVEPOINT sp;
|
|
|
|
WARNING: there is no transaction in progress
|
|
|
|
ERROR: SAVEPOINT can only be used in transaction blocks
|
|
|
|
ROLLBACK TO SAVEPOINT sp\; SELECT 2;
|
|
|
|
ERROR: ROLLBACK TO SAVEPOINT can only be used in transaction blocks
|
|
|
|
SELECT 2\; RELEASE SAVEPOINT sp\; SELECT 3;
|
|
|
|
ERROR: RELEASE SAVEPOINT can only be used in transaction blocks
|
|
|
|
-- but this is OK, because the BEGIN converts it to a regular xact
|
|
|
|
SELECT 1\; BEGIN\; SAVEPOINT sp\; ROLLBACK TO SAVEPOINT sp\; COMMIT;
|
2012-02-15 22:18:34 +01:00
|
|
|
-- Test for successful cleanup of an aborted transaction at session exit.
|
|
|
|
-- THIS MUST BE THE LAST TEST IN THIS FILE.
|
|
|
|
begin;
|
|
|
|
select 1/0;
|
|
|
|
ERROR: division by zero
|
|
|
|
rollback to X;
|
|
|
|
ERROR: no such savepoint
|
|
|
|
-- DO NOT ADD ANYTHING HERE.
|