2007-03-13 01:33:44 +01:00
|
|
|
--
|
|
|
|
-- Tests to exercise the plan caching/invalidation mechanism
|
|
|
|
--
|
2007-03-16 17:11:49 +01:00
|
|
|
CREATE TEMP TABLE pcachetest AS SELECT * FROM int8_tbl;
|
2007-03-13 01:33:44 +01:00
|
|
|
-- create and use a cached plan
|
2007-03-16 17:11:49 +01:00
|
|
|
PREPARE prepstmt AS SELECT * FROM pcachetest;
|
2007-03-13 01:33:44 +01:00
|
|
|
EXECUTE prepstmt;
|
|
|
|
q1 | q2
|
|
|
|
------------------+-------------------
|
|
|
|
123 | 456
|
|
|
|
123 | 4567890123456789
|
|
|
|
4567890123456789 | 123
|
|
|
|
4567890123456789 | 4567890123456789
|
|
|
|
4567890123456789 | -4567890123456789
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
-- and one with parameters
|
2007-03-16 17:11:49 +01:00
|
|
|
PREPARE prepstmt2(bigint) AS SELECT * FROM pcachetest WHERE q1 = $1;
|
2007-03-13 01:33:44 +01:00
|
|
|
EXECUTE prepstmt2(123);
|
|
|
|
q1 | q2
|
|
|
|
-----+------------------
|
|
|
|
123 | 456
|
|
|
|
123 | 4567890123456789
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- invalidate the plans and see what happens
|
2007-03-16 17:11:49 +01:00
|
|
|
DROP TABLE pcachetest;
|
2007-03-13 01:33:44 +01:00
|
|
|
EXECUTE prepstmt;
|
2007-03-16 17:11:49 +01:00
|
|
|
ERROR: relation "pcachetest" does not exist
|
2007-03-13 01:33:44 +01:00
|
|
|
EXECUTE prepstmt2(123);
|
2007-03-16 17:11:49 +01:00
|
|
|
ERROR: relation "pcachetest" does not exist
|
2007-03-13 01:33:44 +01:00
|
|
|
-- recreate the temp table (this demonstrates that the raw plan is
|
|
|
|
-- purely textual and doesn't depend on OIDs, for instance)
|
2007-03-16 17:11:49 +01:00
|
|
|
CREATE TEMP TABLE pcachetest AS SELECT * FROM int8_tbl ORDER BY 2;
|
2007-03-13 01:33:44 +01:00
|
|
|
EXECUTE prepstmt;
|
|
|
|
q1 | q2
|
|
|
|
------------------+-------------------
|
|
|
|
4567890123456789 | -4567890123456789
|
|
|
|
4567890123456789 | 123
|
|
|
|
123 | 456
|
|
|
|
123 | 4567890123456789
|
|
|
|
4567890123456789 | 4567890123456789
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
EXECUTE prepstmt2(123);
|
|
|
|
q1 | q2
|
|
|
|
-----+------------------
|
|
|
|
123 | 456
|
|
|
|
123 | 4567890123456789
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- prepared statements should prevent change in output tupdesc,
|
|
|
|
-- since clients probably aren't expecting that to change on the fly
|
2007-03-16 17:11:49 +01:00
|
|
|
ALTER TABLE pcachetest ADD COLUMN q3 bigint;
|
2007-03-13 01:33:44 +01:00
|
|
|
EXECUTE prepstmt;
|
|
|
|
ERROR: cached plan must not change result type
|
|
|
|
EXECUTE prepstmt2(123);
|
|
|
|
ERROR: cached plan must not change result type
|
|
|
|
-- but we're nice guys and will let you undo your mistake
|
2007-03-16 17:11:49 +01:00
|
|
|
ALTER TABLE pcachetest DROP COLUMN q3;
|
2007-03-13 01:33:44 +01:00
|
|
|
EXECUTE prepstmt;
|
|
|
|
q1 | q2
|
|
|
|
------------------+-------------------
|
|
|
|
4567890123456789 | -4567890123456789
|
|
|
|
4567890123456789 | 123
|
|
|
|
123 | 456
|
|
|
|
123 | 4567890123456789
|
|
|
|
4567890123456789 | 4567890123456789
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
EXECUTE prepstmt2(123);
|
|
|
|
q1 | q2
|
|
|
|
-----+------------------
|
|
|
|
123 | 456
|
|
|
|
123 | 4567890123456789
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- Try it with a view, which isn't directly used in the resulting plan
|
|
|
|
-- but should trigger invalidation anyway
|
2007-03-16 17:11:49 +01:00
|
|
|
CREATE TEMP VIEW pcacheview AS
|
|
|
|
SELECT * FROM pcachetest;
|
|
|
|
PREPARE vprep AS SELECT * FROM pcacheview;
|
2007-03-13 01:33:44 +01:00
|
|
|
EXECUTE vprep;
|
|
|
|
q1 | q2
|
|
|
|
------------------+-------------------
|
|
|
|
4567890123456789 | -4567890123456789
|
|
|
|
4567890123456789 | 123
|
|
|
|
123 | 456
|
|
|
|
123 | 4567890123456789
|
|
|
|
4567890123456789 | 4567890123456789
|
|
|
|
(5 rows)
|
|
|
|
|
2007-03-16 17:11:49 +01:00
|
|
|
CREATE OR REPLACE TEMP VIEW pcacheview AS
|
|
|
|
SELECT q1, q2/2 AS q2 FROM pcachetest;
|
2007-03-13 01:33:44 +01:00
|
|
|
EXECUTE vprep;
|
|
|
|
q1 | q2
|
|
|
|
------------------+-------------------
|
|
|
|
4567890123456789 | -2283945061728394
|
|
|
|
4567890123456789 | 61
|
|
|
|
123 | 228
|
|
|
|
123 | 2283945061728394
|
|
|
|
4567890123456789 | 2283945061728394
|
|
|
|
(5 rows)
|
|
|
|
|
2007-03-16 00:12:07 +01:00
|
|
|
-- Check basic SPI plan invalidation
|
|
|
|
create function cache_test(int) returns int as $$
|
|
|
|
declare total int;
|
|
|
|
begin
|
|
|
|
create temp table t1(f1 int);
|
|
|
|
insert into t1 values($1);
|
|
|
|
insert into t1 values(11);
|
|
|
|
insert into t1 values(12);
|
|
|
|
insert into t1 values(13);
|
|
|
|
select sum(f1) into total from t1;
|
|
|
|
drop table t1;
|
|
|
|
return total;
|
|
|
|
end
|
|
|
|
$$ language plpgsql;
|
|
|
|
select cache_test(1);
|
|
|
|
cache_test
|
|
|
|
------------
|
|
|
|
37
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select cache_test(2);
|
|
|
|
cache_test
|
|
|
|
------------
|
|
|
|
38
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select cache_test(3);
|
|
|
|
cache_test
|
|
|
|
------------
|
|
|
|
39
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Check invalidation of plpgsql "simple expression"
|
|
|
|
create temp view v1 as
|
|
|
|
select 2+2 as f1;
|
|
|
|
create function cache_test_2() returns int as $$
|
|
|
|
begin
|
|
|
|
return f1 from v1;
|
|
|
|
end$$ language plpgsql;
|
|
|
|
select cache_test_2();
|
|
|
|
cache_test_2
|
|
|
|
--------------
|
|
|
|
4
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
create or replace temp view v1 as
|
|
|
|
select 2+2+4 as f1;
|
|
|
|
select cache_test_2();
|
|
|
|
cache_test_2
|
|
|
|
--------------
|
|
|
|
8
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
create or replace temp view v1 as
|
|
|
|
select 2+2+4+(select max(unique1) from tenk1) as f1;
|
|
|
|
select cache_test_2();
|
|
|
|
cache_test_2
|
|
|
|
--------------
|
|
|
|
10007
|
|
|
|
(1 row)
|
|
|
|
|
Change plan caching to honor, not resist, changes in search_path.
In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan. The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes. Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids. So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.
This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution. There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse. We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
2013-01-25 20:14:41 +01:00
|
|
|
--- Check that change of search_path is honored when re-using cached plan
|
2007-03-23 20:53:52 +01:00
|
|
|
create schema s1
|
|
|
|
create table abc (f1 int);
|
|
|
|
create schema s2
|
|
|
|
create table abc (f1 int);
|
|
|
|
insert into s1.abc values(123);
|
|
|
|
insert into s2.abc values(456);
|
|
|
|
set search_path = s1;
|
|
|
|
prepare p1 as select f1 from abc;
|
|
|
|
execute p1;
|
|
|
|
f1
|
|
|
|
-----
|
|
|
|
123
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
set search_path = s2;
|
|
|
|
select f1 from abc;
|
|
|
|
f1
|
|
|
|
-----
|
|
|
|
456
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
execute p1;
|
|
|
|
f1
|
|
|
|
-----
|
Change plan caching to honor, not resist, changes in search_path.
In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan. The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes. Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids. So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.
This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution. There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse. We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
2013-01-25 20:14:41 +01:00
|
|
|
456
|
2007-03-23 20:53:52 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
alter table s1.abc add column f2 float8; -- force replan
|
|
|
|
execute p1;
|
|
|
|
f1
|
|
|
|
-----
|
Change plan caching to honor, not resist, changes in search_path.
In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan. The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes. Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids. So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.
This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution. There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse. We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
2013-01-25 20:14:41 +01:00
|
|
|
456
|
2007-03-23 20:53:52 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
drop schema s1 cascade;
|
|
|
|
NOTICE: drop cascades to table s1.abc
|
|
|
|
drop schema s2 cascade;
|
|
|
|
NOTICE: drop cascades to table abc
|
2007-11-30 19:38:34 +01:00
|
|
|
reset search_path;
|
2007-10-11 20:05:27 +02:00
|
|
|
-- Check that invalidation deals with regclass constants
|
|
|
|
create temp sequence seq;
|
|
|
|
prepare p2 as select nextval('seq');
|
|
|
|
execute p2;
|
|
|
|
nextval
|
|
|
|
---------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
drop sequence seq;
|
|
|
|
create temp sequence seq;
|
|
|
|
execute p2;
|
|
|
|
nextval
|
|
|
|
---------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
2007-11-30 19:38:34 +01:00
|
|
|
-- Check DDL via SPI, immediately followed by SPI plan re-use
|
|
|
|
-- (bug in original coding)
|
|
|
|
create function cachebug() returns void as $$
|
|
|
|
declare r int;
|
|
|
|
begin
|
|
|
|
drop table if exists temptable cascade;
|
|
|
|
create temp table temptable as select * from generate_series(1,3) as f1;
|
|
|
|
create temp view vv as select * from temptable;
|
|
|
|
for r in select * from vv loop
|
|
|
|
raise notice '%', r;
|
|
|
|
end loop;
|
|
|
|
end$$ language plpgsql;
|
|
|
|
select cachebug();
|
|
|
|
NOTICE: table "temptable" does not exist, skipping
|
|
|
|
NOTICE: 1
|
|
|
|
NOTICE: 2
|
|
|
|
NOTICE: 3
|
|
|
|
cachebug
|
|
|
|
----------
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select cachebug();
|
|
|
|
NOTICE: drop cascades to view vv
|
|
|
|
NOTICE: 1
|
|
|
|
NOTICE: 2
|
|
|
|
NOTICE: 3
|
|
|
|
cachebug
|
|
|
|
----------
|
|
|
|
|
|
|
|
(1 row)
|
|
|
|
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
-- Check that addition or removal of any partition is correctly dealt with by
|
|
|
|
-- default partition table when it is being used in prepared statement.
|
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 pc_list_parted (a int) partition by list(a);
|
|
|
|
create table pc_list_part_null partition of pc_list_parted for values in (null);
|
|
|
|
create table pc_list_part_1 partition of pc_list_parted for values in (1);
|
|
|
|
create table pc_list_part_def partition of pc_list_parted default;
|
|
|
|
prepare pstmt_def_insert (int) as insert into pc_list_part_def values($1);
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
-- should fail
|
|
|
|
execute pstmt_def_insert(null);
|
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
|
|
|
ERROR: new row for relation "pc_list_part_def" violates partition constraint
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
DETAIL: Failing row contains (null).
|
|
|
|
execute pstmt_def_insert(1);
|
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
|
|
|
ERROR: new row for relation "pc_list_part_def" violates partition constraint
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
DETAIL: Failing row contains (1).
|
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 pc_list_part_2 partition of pc_list_parted for values in (2);
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
execute pstmt_def_insert(2);
|
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
|
|
|
ERROR: new row for relation "pc_list_part_def" violates partition constraint
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
DETAIL: Failing row contains (2).
|
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
|
|
|
alter table pc_list_parted detach partition pc_list_part_null;
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
-- should be ok
|
|
|
|
execute pstmt_def_insert(null);
|
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 pc_list_part_1;
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
-- should be ok
|
|
|
|
execute pstmt_def_insert(1);
|
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 pc_list_parted, pc_list_part_null;
|
Allow a partitioned table to have a default partition.
Any tuples that don't route to any other partition will route to the
default partition.
Jeevan Ladhe, Beena Emerson, Ashutosh Bapat, Rahila Syed, and Robert
Haas, with review and testing at various stages by (at least) Rushabh
Lathia, Keith Fiske, Amit Langote, Amul Sul, Rajkumar Raghuanshi, Sven
Kunze, Kyotaro Horiguchi, Thom Brown, Rafia Sabih, and Dilip Kumar.
Discussion: http://postgr.es/m/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com
Discussion: http://postgr.es/m/CAOG9ApEYj34fWMcvBMBQ-YtqR9fTdXhdN82QEKG0SVZ6zeL1xg@mail.gmail.com
2017-09-08 23:28:04 +02:00
|
|
|
deallocate pstmt_def_insert;
|
2018-07-16 13:35:41 +02:00
|
|
|
-- Test plan_cache_mode
|
|
|
|
create table test_mode (a int);
|
|
|
|
insert into test_mode select 1 from generate_series(1,1000) union all select 2;
|
|
|
|
create index on test_mode (a);
|
|
|
|
analyze test_mode;
|
|
|
|
prepare test_mode_pp (int) as select count(*) from test_mode where a = $1;
|
2020-07-20 04:55:50 +02:00
|
|
|
select name, generic_plans, custom_plans from pg_prepared_statements
|
|
|
|
where name = 'test_mode_pp';
|
|
|
|
name | generic_plans | custom_plans
|
|
|
|
--------------+---------------+--------------
|
|
|
|
test_mode_pp | 0 | 0
|
|
|
|
(1 row)
|
|
|
|
|
2018-07-16 13:35:41 +02:00
|
|
|
-- up to 5 executions, custom plan is used
|
2020-07-20 04:55:50 +02:00
|
|
|
set plan_cache_mode to auto;
|
2018-07-16 13:35:41 +02:00
|
|
|
explain (costs off) execute test_mode_pp(2);
|
|
|
|
QUERY PLAN
|
|
|
|
----------------------------------------------------------
|
|
|
|
Aggregate
|
|
|
|
-> Index Only Scan using test_mode_a_idx on test_mode
|
|
|
|
Index Cond: (a = 2)
|
|
|
|
(3 rows)
|
|
|
|
|
2020-07-20 04:55:50 +02:00
|
|
|
select name, generic_plans, custom_plans from pg_prepared_statements
|
|
|
|
where name = 'test_mode_pp';
|
|
|
|
name | generic_plans | custom_plans
|
|
|
|
--------------+---------------+--------------
|
|
|
|
test_mode_pp | 0 | 1
|
|
|
|
(1 row)
|
|
|
|
|
2018-07-16 13:35:41 +02:00
|
|
|
-- force generic plan
|
|
|
|
set plan_cache_mode to force_generic_plan;
|
|
|
|
explain (costs off) execute test_mode_pp(2);
|
|
|
|
QUERY PLAN
|
|
|
|
-----------------------------
|
|
|
|
Aggregate
|
|
|
|
-> Seq Scan on test_mode
|
|
|
|
Filter: (a = $1)
|
|
|
|
(3 rows)
|
|
|
|
|
2020-07-20 04:55:50 +02:00
|
|
|
select name, generic_plans, custom_plans from pg_prepared_statements
|
|
|
|
where name = 'test_mode_pp';
|
|
|
|
name | generic_plans | custom_plans
|
|
|
|
--------------+---------------+--------------
|
|
|
|
test_mode_pp | 1 | 1
|
|
|
|
(1 row)
|
|
|
|
|
2018-07-16 13:35:41 +02:00
|
|
|
-- get to generic plan by 5 executions
|
|
|
|
set plan_cache_mode to auto;
|
|
|
|
execute test_mode_pp(1); -- 1x
|
|
|
|
count
|
|
|
|
-------
|
|
|
|
1000
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
execute test_mode_pp(1); -- 2x
|
|
|
|
count
|
|
|
|
-------
|
|
|
|
1000
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
execute test_mode_pp(1); -- 3x
|
|
|
|
count
|
|
|
|
-------
|
|
|
|
1000
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
execute test_mode_pp(1); -- 4x
|
|
|
|
count
|
|
|
|
-------
|
|
|
|
1000
|
|
|
|
(1 row)
|
|
|
|
|
2020-07-20 04:55:50 +02:00
|
|
|
select name, generic_plans, custom_plans from pg_prepared_statements
|
|
|
|
where name = 'test_mode_pp';
|
|
|
|
name | generic_plans | custom_plans
|
|
|
|
--------------+---------------+--------------
|
|
|
|
test_mode_pp | 1 | 5
|
|
|
|
(1 row)
|
|
|
|
|
2018-07-16 13:35:41 +02:00
|
|
|
execute test_mode_pp(1); -- 5x
|
|
|
|
count
|
|
|
|
-------
|
|
|
|
1000
|
|
|
|
(1 row)
|
|
|
|
|
2020-07-20 04:55:50 +02:00
|
|
|
select name, generic_plans, custom_plans from pg_prepared_statements
|
|
|
|
where name = 'test_mode_pp';
|
|
|
|
name | generic_plans | custom_plans
|
|
|
|
--------------+---------------+--------------
|
|
|
|
test_mode_pp | 2 | 5
|
|
|
|
(1 row)
|
|
|
|
|
2018-07-16 13:35:41 +02:00
|
|
|
-- we should now get a really bad plan
|
|
|
|
explain (costs off) execute test_mode_pp(2);
|
|
|
|
QUERY PLAN
|
|
|
|
-----------------------------
|
|
|
|
Aggregate
|
|
|
|
-> Seq Scan on test_mode
|
|
|
|
Filter: (a = $1)
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
-- but we can force a custom plan
|
|
|
|
set plan_cache_mode to force_custom_plan;
|
|
|
|
explain (costs off) execute test_mode_pp(2);
|
|
|
|
QUERY PLAN
|
|
|
|
----------------------------------------------------------
|
|
|
|
Aggregate
|
|
|
|
-> Index Only Scan using test_mode_a_idx on test_mode
|
|
|
|
Index Cond: (a = 2)
|
|
|
|
(3 rows)
|
|
|
|
|
2020-07-20 04:55:50 +02:00
|
|
|
select name, generic_plans, custom_plans from pg_prepared_statements
|
|
|
|
where name = 'test_mode_pp';
|
|
|
|
name | generic_plans | custom_plans
|
|
|
|
--------------+---------------+--------------
|
|
|
|
test_mode_pp | 3 | 6
|
|
|
|
(1 row)
|
|
|
|
|
2018-07-16 13:35:41 +02:00
|
|
|
drop table test_mode;
|