2015-10-03 12:19:37 -04:00
|
|
|
-- test some errors
|
|
|
|
|
CREATE EXTENSION test_ext1;
|
|
|
|
|
CREATE EXTENSION test_ext1 SCHEMA test_ext1;
|
|
|
|
|
CREATE EXTENSION test_ext1 SCHEMA test_ext;
|
|
|
|
|
CREATE SCHEMA test_ext;
|
|
|
|
|
CREATE EXTENSION test_ext1 SCHEMA test_ext;
|
|
|
|
|
|
|
|
|
|
-- finally success
|
|
|
|
|
CREATE EXTENSION test_ext1 SCHEMA test_ext CASCADE;
|
|
|
|
|
|
|
|
|
|
SELECT extname, nspname, extversion, extrelocatable FROM pg_extension e, pg_namespace n WHERE extname LIKE 'test_ext%' AND e.extnamespace = n.oid ORDER BY 1;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cyclic1 CASCADE;
|
|
|
|
|
|
|
|
|
|
DROP SCHEMA test_ext CASCADE;
|
2016-04-15 21:57:15 -04:00
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext6;
|
|
|
|
|
DROP EXTENSION test_ext6;
|
|
|
|
|
CREATE EXTENSION test_ext6;
|
Fix test about ignoring extension dependencies during extension scripts.
Commit 08dd23cec introduced an exception to the rule that extension member
objects can only be dropped as part of dropping the whole extension,
intending to allow such drops while running the extension's own creation or
update scripts. However, the exception was only applied at the outermost
recursion level, because it was modeled on a pre-existing check to ignore
dependencies on objects listed in pendingObjects. Bug #14434 from Philippe
Beaudoin shows that this is inadequate: in some cases we can reach an
extension member object by recursion from another one. (The bug concerns
the serial-sequence case; I'm not sure if there are other cases, but there
might well be.)
To fix, revert 08dd23cec's changes to findDependentObjects() and instead
apply the creating_extension exception regardless of stack level.
Having seen this example, I'm a bit suspicious that the pendingObjects
logic is also wrong and such cases should likewise be allowed at any
recursion level. However, changing that would interact in subtle ways
with the recursion logic (at least it would need to be moved to after the
recursing-from check). Given that the code's been like that a long time,
I'll refrain from touching it without a clear example showing it's wrong.
Back-patch to all active branches. In HEAD and 9.6, where suitable
test infrastructure exists, add a regression test case based on the
bug report.
Report: <20161125151448.6529.33039@wrigleys.postgresql.org>
Discussion: <13224.1480177514@sss.pgh.pa.us>
2016-11-26 13:31:35 -05:00
|
|
|
|
|
|
|
|
-- test dropping of member tables that own extensions:
|
|
|
|
|
-- this table will be absorbed into test_ext7
|
|
|
|
|
create table old_table1 (col1 serial primary key);
|
|
|
|
|
create extension test_ext7;
|
|
|
|
|
\dx+ test_ext7
|
|
|
|
|
alter extension test_ext7 update to '2.0';
|
|
|
|
|
\dx+ test_ext7
|
Delete deleteWhatDependsOn() in favor of more performDeletion() flag bits.
deleteWhatDependsOn() had grown an uncomfortably large number of
assumptions about what it's used for. There are actually only two minor
differences between what it does and what a regular performDeletion() call
can do, so let's invent additional bits in performDeletion's existing flags
argument that specify those behaviors, and get rid of deleteWhatDependsOn()
as such. (We'd probably have done it this way from the start, except that
performDeletion didn't originally have a flags argument, IIRC.)
Also, add a SKIP_EXTENSIONS flag bit that prevents ever recursing to an
extension, and use that when dropping temporary objects at session end.
This provides a more general solution to the problem addressed in a hacky
way in commit 08dd23cec: if an extension script creates temp objects and
forgets to remove them again, the whole extension went away when its
contained temp objects were deleted. The previous solution only covered
temp relations, but this solves it for all object types.
These changes require minor additions in dependency.c to pass the flags
to subroutines that previously didn't get them, but it's still a net
savings of code, and it seems cleaner than before.
Having done this, revert the special-case code added in 08dd23cec that
prevented addition of pg_depend records for temp table extension
membership, because that caused its own oddities: dropping an extension
that had created such a table didn't automatically remove the table,
leading to a failure if the table had another dependency on the extension
(such as use of an extension data type), or to a duplicate-name failure if
you then tried to recreate the extension. But we keep the part that
prevents the pg_temp_nnn schema from becoming an extension member; we never
want that to happen. Add a regression test case covering these behaviors.
Although this fixes some arguable bugs, we've heard few field complaints,
and any such problems are easily worked around by explicitly dropping temp
objects at the end of extension scripts (which seems like good practice
anyway). So I won't risk a back-patch.
Discussion: https://postgr.es/m/e51f4311-f483-4dd0-1ccc-abec3c405110@BlueTreble.com
2016-12-02 14:57:35 -05:00
|
|
|
|
|
|
|
|
-- test handling of temp objects created by extensions
|
|
|
|
|
create extension test_ext8;
|
|
|
|
|
|
|
|
|
|
-- \dx+ would expose a variable pg_temp_nn schema name, so we can't use it here
|
|
|
|
|
select regexp_replace(pg_describe_object(classid, objid, objsubid),
|
2017-06-13 14:38:35 -04:00
|
|
|
'pg_temp_\d+', 'pg_temp', 'g') as "Object description"
|
Delete deleteWhatDependsOn() in favor of more performDeletion() flag bits.
deleteWhatDependsOn() had grown an uncomfortably large number of
assumptions about what it's used for. There are actually only two minor
differences between what it does and what a regular performDeletion() call
can do, so let's invent additional bits in performDeletion's existing flags
argument that specify those behaviors, and get rid of deleteWhatDependsOn()
as such. (We'd probably have done it this way from the start, except that
performDeletion didn't originally have a flags argument, IIRC.)
Also, add a SKIP_EXTENSIONS flag bit that prevents ever recursing to an
extension, and use that when dropping temporary objects at session end.
This provides a more general solution to the problem addressed in a hacky
way in commit 08dd23cec: if an extension script creates temp objects and
forgets to remove them again, the whole extension went away when its
contained temp objects were deleted. The previous solution only covered
temp relations, but this solves it for all object types.
These changes require minor additions in dependency.c to pass the flags
to subroutines that previously didn't get them, but it's still a net
savings of code, and it seems cleaner than before.
Having done this, revert the special-case code added in 08dd23cec that
prevented addition of pg_depend records for temp table extension
membership, because that caused its own oddities: dropping an extension
that had created such a table didn't automatically remove the table,
leading to a failure if the table had another dependency on the extension
(such as use of an extension data type), or to a duplicate-name failure if
you then tried to recreate the extension. But we keep the part that
prevents the pg_temp_nnn schema from becoming an extension member; we never
want that to happen. Add a regression test case covering these behaviors.
Although this fixes some arguable bugs, we've heard few field complaints,
and any such problems are easily worked around by explicitly dropping temp
objects at the end of extension scripts (which seems like good practice
anyway). So I won't risk a back-patch.
Discussion: https://postgr.es/m/e51f4311-f483-4dd0-1ccc-abec3c405110@BlueTreble.com
2016-12-02 14:57:35 -05:00
|
|
|
from pg_depend
|
|
|
|
|
where refclassid = 'pg_extension'::regclass and deptype = 'e' and
|
|
|
|
|
refobjid = (select oid from pg_extension where extname = 'test_ext8')
|
|
|
|
|
order by 1;
|
|
|
|
|
|
|
|
|
|
-- Should be possible to drop and recreate this extension
|
|
|
|
|
drop extension test_ext8;
|
|
|
|
|
create extension test_ext8;
|
|
|
|
|
|
|
|
|
|
select regexp_replace(pg_describe_object(classid, objid, objsubid),
|
2017-06-13 14:38:35 -04:00
|
|
|
'pg_temp_\d+', 'pg_temp', 'g') as "Object description"
|
Delete deleteWhatDependsOn() in favor of more performDeletion() flag bits.
deleteWhatDependsOn() had grown an uncomfortably large number of
assumptions about what it's used for. There are actually only two minor
differences between what it does and what a regular performDeletion() call
can do, so let's invent additional bits in performDeletion's existing flags
argument that specify those behaviors, and get rid of deleteWhatDependsOn()
as such. (We'd probably have done it this way from the start, except that
performDeletion didn't originally have a flags argument, IIRC.)
Also, add a SKIP_EXTENSIONS flag bit that prevents ever recursing to an
extension, and use that when dropping temporary objects at session end.
This provides a more general solution to the problem addressed in a hacky
way in commit 08dd23cec: if an extension script creates temp objects and
forgets to remove them again, the whole extension went away when its
contained temp objects were deleted. The previous solution only covered
temp relations, but this solves it for all object types.
These changes require minor additions in dependency.c to pass the flags
to subroutines that previously didn't get them, but it's still a net
savings of code, and it seems cleaner than before.
Having done this, revert the special-case code added in 08dd23cec that
prevented addition of pg_depend records for temp table extension
membership, because that caused its own oddities: dropping an extension
that had created such a table didn't automatically remove the table,
leading to a failure if the table had another dependency on the extension
(such as use of an extension data type), or to a duplicate-name failure if
you then tried to recreate the extension. But we keep the part that
prevents the pg_temp_nnn schema from becoming an extension member; we never
want that to happen. Add a regression test case covering these behaviors.
Although this fixes some arguable bugs, we've heard few field complaints,
and any such problems are easily worked around by explicitly dropping temp
objects at the end of extension scripts (which seems like good practice
anyway). So I won't risk a back-patch.
Discussion: https://postgr.es/m/e51f4311-f483-4dd0-1ccc-abec3c405110@BlueTreble.com
2016-12-02 14:57:35 -05:00
|
|
|
from pg_depend
|
|
|
|
|
where refclassid = 'pg_extension'::regclass and deptype = 'e' and
|
|
|
|
|
refobjid = (select oid from pg_extension where extname = 'test_ext8')
|
|
|
|
|
order by 1;
|
|
|
|
|
|
|
|
|
|
-- here we want to start a new session and wait till old one is gone
|
|
|
|
|
select pg_backend_pid() as oldpid \gset
|
|
|
|
|
\c -
|
|
|
|
|
do 'declare c int = 0;
|
|
|
|
|
begin
|
|
|
|
|
while (select count(*) from pg_stat_activity where pid = '
|
|
|
|
|
:'oldpid'
|
2016-12-02 17:23:54 -05:00
|
|
|
') > 0 loop c := c + 1; perform pg_stat_clear_snapshot(); end loop;
|
Delete deleteWhatDependsOn() in favor of more performDeletion() flag bits.
deleteWhatDependsOn() had grown an uncomfortably large number of
assumptions about what it's used for. There are actually only two minor
differences between what it does and what a regular performDeletion() call
can do, so let's invent additional bits in performDeletion's existing flags
argument that specify those behaviors, and get rid of deleteWhatDependsOn()
as such. (We'd probably have done it this way from the start, except that
performDeletion didn't originally have a flags argument, IIRC.)
Also, add a SKIP_EXTENSIONS flag bit that prevents ever recursing to an
extension, and use that when dropping temporary objects at session end.
This provides a more general solution to the problem addressed in a hacky
way in commit 08dd23cec: if an extension script creates temp objects and
forgets to remove them again, the whole extension went away when its
contained temp objects were deleted. The previous solution only covered
temp relations, but this solves it for all object types.
These changes require minor additions in dependency.c to pass the flags
to subroutines that previously didn't get them, but it's still a net
savings of code, and it seems cleaner than before.
Having done this, revert the special-case code added in 08dd23cec that
prevented addition of pg_depend records for temp table extension
membership, because that caused its own oddities: dropping an extension
that had created such a table didn't automatically remove the table,
leading to a failure if the table had another dependency on the extension
(such as use of an extension data type), or to a duplicate-name failure if
you then tried to recreate the extension. But we keep the part that
prevents the pg_temp_nnn schema from becoming an extension member; we never
want that to happen. Add a regression test case covering these behaviors.
Although this fixes some arguable bugs, we've heard few field complaints,
and any such problems are easily worked around by explicitly dropping temp
objects at the end of extension scripts (which seems like good practice
anyway). So I won't risk a back-patch.
Discussion: https://postgr.es/m/e51f4311-f483-4dd0-1ccc-abec3c405110@BlueTreble.com
2016-12-02 14:57:35 -05:00
|
|
|
raise log ''test_extensions looped % times'', c;
|
|
|
|
|
end';
|
|
|
|
|
|
|
|
|
|
-- extension should now contain no temp objects
|
|
|
|
|
\dx+ test_ext8
|
|
|
|
|
|
|
|
|
|
-- dropping it should still work
|
|
|
|
|
drop extension test_ext8;
|
Restrict the use of temporary namespace in two-phase transactions
Attempting to use a temporary table within a two-phase transaction is
forbidden for ages. However, there have been uncovered grounds for
a couple of other object types and commands which work on temporary
objects with two-phase commit. In short, trying to create, lock or drop
an object on a temporary schema should not be authorized within a
two-phase transaction, as it would cause its state to create
dependencies with other sessions, causing all sorts of side effects with
the existing session or other sessions spawned later on trying to use
the same temporary schema name.
Regression tests are added to cover all the grounds found, the original
report mentioned function creation, but monitoring closer there are many
other patterns with LOCK, DROP or CREATE EXTENSION which are involved.
One of the symptoms resulting in combining both is that the session
which used the temporary schema is not able to shut down completely,
waiting for being able to drop the temporary schema, something that it
cannot complete because of the two-phase transaction involved with
temporary objects. In this case the client is able to disconnect but
the session remains alive on the backend-side, potentially blocking
connection backend slots from being used. Other problems reported could
also involve server crashes.
This is back-patched down to v10, which is where 9b013dc has introduced
MyXactFlags, something that this patch relies on.
Reported-by: Alexey Bashtanov
Author: Michael Paquier
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/5d910e2e-0db8-ec06-dd5f-baec420513c3@imap.cc
Backpatch-through: 10
2019-01-17 19:21:44 -05:00
|
|
|
|
|
|
|
|
-- Test creation of extension in temporary schema with two-phase commit,
|
|
|
|
|
-- which should not work. This function wrapper is useful for portability.
|
|
|
|
|
|
|
|
|
|
-- Avoid noise caused by CONTEXT and NOTICE messages including the temporary
|
|
|
|
|
-- schema name.
|
|
|
|
|
\set SHOW_CONTEXT never
|
|
|
|
|
SET client_min_messages TO 'warning';
|
|
|
|
|
-- First enforce presence of temporary schema.
|
|
|
|
|
CREATE TEMP TABLE test_ext4_tab ();
|
|
|
|
|
CREATE OR REPLACE FUNCTION create_extension_with_temp_schema()
|
|
|
|
|
RETURNS VOID AS $$
|
|
|
|
|
DECLARE
|
|
|
|
|
tmpschema text;
|
|
|
|
|
query text;
|
|
|
|
|
BEGIN
|
|
|
|
|
SELECT INTO tmpschema pg_my_temp_schema()::regnamespace;
|
|
|
|
|
query := 'CREATE EXTENSION test_ext4 SCHEMA ' || tmpschema || ' CASCADE;';
|
|
|
|
|
RAISE NOTICE 'query %', query;
|
|
|
|
|
EXECUTE query;
|
|
|
|
|
END; $$ LANGUAGE plpgsql;
|
|
|
|
|
BEGIN;
|
|
|
|
|
SELECT create_extension_with_temp_schema();
|
|
|
|
|
PREPARE TRANSACTION 'twophase_extension';
|
|
|
|
|
-- Clean up
|
|
|
|
|
DROP TABLE test_ext4_tab;
|
|
|
|
|
DROP FUNCTION create_extension_with_temp_schema();
|
|
|
|
|
RESET client_min_messages;
|
|
|
|
|
\unset SHOW_CONTEXT
|
2020-09-15 20:03:14 -04:00
|
|
|
|
|
|
|
|
-- Test case of an event trigger run in an extension upgrade script.
|
|
|
|
|
-- See: https://postgr.es/m/20200902193715.6e0269d4@firost
|
|
|
|
|
CREATE EXTENSION test_ext_evttrig;
|
|
|
|
|
ALTER EXTENSION test_ext_evttrig UPDATE TO '2.0';
|
|
|
|
|
DROP EXTENSION test_ext_evttrig;
|
2022-08-08 11:12:31 -04:00
|
|
|
|
|
|
|
|
-- It's generally bad style to use CREATE OR REPLACE unnecessarily.
|
|
|
|
|
-- Test what happens if an extension does it anyway.
|
|
|
|
|
-- Replacing a shell type or operator is sort of like CREATE OR REPLACE;
|
|
|
|
|
-- check that too.
|
|
|
|
|
|
|
|
|
|
CREATE FUNCTION ext_cor_func() RETURNS text
|
|
|
|
|
AS $$ SELECT 'ext_cor_func: original'::text $$ LANGUAGE sql;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cor; -- fail
|
|
|
|
|
|
|
|
|
|
SELECT ext_cor_func();
|
|
|
|
|
|
|
|
|
|
DROP FUNCTION ext_cor_func();
|
|
|
|
|
|
|
|
|
|
CREATE VIEW ext_cor_view AS
|
|
|
|
|
SELECT 'ext_cor_view: original'::text AS col;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cor; -- fail
|
|
|
|
|
|
|
|
|
|
SELECT ext_cor_func();
|
|
|
|
|
|
|
|
|
|
SELECT * FROM ext_cor_view;
|
|
|
|
|
|
|
|
|
|
DROP VIEW ext_cor_view;
|
|
|
|
|
|
|
|
|
|
CREATE TYPE test_ext_type;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cor; -- fail
|
|
|
|
|
|
|
|
|
|
DROP TYPE test_ext_type;
|
|
|
|
|
|
|
|
|
|
-- this makes a shell "point <<@@ polygon" operator too
|
|
|
|
|
CREATE OPERATOR @@>> ( PROCEDURE = poly_contain_pt,
|
|
|
|
|
LEFTARG = polygon, RIGHTARG = point,
|
|
|
|
|
COMMUTATOR = <<@@ );
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cor; -- fail
|
|
|
|
|
|
|
|
|
|
DROP OPERATOR <<@@ (point, polygon);
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cor; -- now it should work
|
|
|
|
|
|
|
|
|
|
SELECT ext_cor_func();
|
|
|
|
|
|
|
|
|
|
SELECT * FROM ext_cor_view;
|
|
|
|
|
|
|
|
|
|
SELECT 'x'::test_ext_type;
|
|
|
|
|
|
|
|
|
|
SELECT point(0,0) <<@@ polygon(circle(point(0,0),1));
|
|
|
|
|
|
|
|
|
|
\dx+ test_ext_cor
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
-- CREATE IF NOT EXISTS is an entirely unsound thing for an extension
|
|
|
|
|
-- to be doing, but let's at least plug the major security hole in it.
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
CREATE COLLATION ext_cine_coll
|
|
|
|
|
( LC_COLLATE = "C", LC_CTYPE = "C" );
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cine; -- fail
|
|
|
|
|
|
|
|
|
|
DROP COLLATION ext_cine_coll;
|
|
|
|
|
|
|
|
|
|
CREATE MATERIALIZED VIEW ext_cine_mv AS SELECT 11 AS f1;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cine; -- fail
|
|
|
|
|
|
|
|
|
|
DROP MATERIALIZED VIEW ext_cine_mv;
|
|
|
|
|
|
|
|
|
|
CREATE FOREIGN DATA WRAPPER dummy;
|
|
|
|
|
|
|
|
|
|
CREATE SERVER ext_cine_srv FOREIGN DATA WRAPPER dummy;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cine; -- fail
|
|
|
|
|
|
|
|
|
|
DROP SERVER ext_cine_srv;
|
|
|
|
|
|
|
|
|
|
CREATE SCHEMA ext_cine_schema;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cine; -- fail
|
|
|
|
|
|
|
|
|
|
DROP SCHEMA ext_cine_schema;
|
|
|
|
|
|
|
|
|
|
CREATE SEQUENCE ext_cine_seq;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cine; -- fail
|
|
|
|
|
|
|
|
|
|
DROP SEQUENCE ext_cine_seq;
|
|
|
|
|
|
|
|
|
|
CREATE TABLE ext_cine_tab1 (x int);
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cine; -- fail
|
|
|
|
|
|
|
|
|
|
DROP TABLE ext_cine_tab1;
|
|
|
|
|
|
|
|
|
|
CREATE TABLE ext_cine_tab2 AS SELECT 42 AS y;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cine; -- fail
|
|
|
|
|
|
|
|
|
|
DROP TABLE ext_cine_tab2;
|
|
|
|
|
|
|
|
|
|
CREATE EXTENSION test_ext_cine;
|
|
|
|
|
|
|
|
|
|
\dx+ test_ext_cine
|
|
|
|
|
|
|
|
|
|
ALTER EXTENSION test_ext_cine UPDATE TO '1.1';
|
|
|
|
|
|
|
|
|
|
\dx+ test_ext_cine
|