2002-07-20 06:58:14 +02:00
|
|
|
--
|
|
|
|
-- VACUUM
|
|
|
|
--
|
|
|
|
CREATE TABLE vactst (i INT);
|
|
|
|
INSERT INTO vactst VALUES (1);
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst VALUES (0);
|
|
|
|
SELECT count(*) FROM vactst;
|
|
|
|
count
|
|
|
|
-------
|
|
|
|
2049
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
DELETE FROM vactst WHERE i != 0;
|
|
|
|
SELECT * FROM vactst;
|
|
|
|
i
|
|
|
|
---
|
|
|
|
0
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
VACUUM FULL vactst;
|
|
|
|
UPDATE vactst SET i = i + 1;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst SELECT * FROM vactst;
|
|
|
|
INSERT INTO vactst VALUES (0);
|
|
|
|
SELECT count(*) FROM vactst;
|
|
|
|
count
|
|
|
|
-------
|
|
|
|
2049
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
DELETE FROM vactst WHERE i != 0;
|
2009-11-16 22:32:07 +01:00
|
|
|
VACUUM (FULL) vactst;
|
2002-07-20 06:58:14 +02:00
|
|
|
DELETE FROM vactst;
|
|
|
|
SELECT * FROM vactst;
|
|
|
|
i
|
|
|
|
---
|
|
|
|
(0 rows)
|
|
|
|
|
2009-11-16 22:32:07 +01:00
|
|
|
VACUUM (FULL, FREEZE) vactst;
|
2010-02-08 05:33:55 +01:00
|
|
|
VACUUM (ANALYZE, FULL) vactst;
|
2010-01-06 06:31:14 +01:00
|
|
|
CREATE TABLE vaccluster (i INT PRIMARY KEY);
|
|
|
|
ALTER TABLE vaccluster CLUSTER ON vaccluster_pkey;
|
|
|
|
CLUSTER vaccluster;
|
2015-01-08 04:33:58 +01:00
|
|
|
CREATE FUNCTION do_analyze() RETURNS VOID VOLATILE LANGUAGE SQL
|
|
|
|
AS 'ANALYZE pg_am';
|
|
|
|
CREATE FUNCTION wrap_do_analyze(c INT) RETURNS INT IMMUTABLE LANGUAGE SQL
|
Fix search_path to a safe value during maintenance operations.
While executing maintenance operations (ANALYZE, CLUSTER, REFRESH
MATERIALIZED VIEW, REINDEX, or VACUUM), set search_path to
'pg_catalog, pg_temp' to prevent inconsistent behavior.
Functions that are used for functional indexes, in index expressions,
or in materialized views and depend on a different search path must be
declared with CREATE FUNCTION ... SET search_path='...'.
This change was previously committed as 05e1737351, then reverted in
commit 2fcc7ee7af because it was too late in the cycle.
Preparation for the MAINTAIN privilege, which was previously reverted
due to search_path manipulation hazards.
Discussion: https://postgr.es/m/d4ccaf3658cb3c281ec88c851a09733cd9482f22.camel@j-davis.com
Discussion: https://postgr.es/m/E1q7j7Y-000z1H-Hr%40gemulon.postgresql.org
Discussion: https://postgr.es/m/e44327179e5c9015c8dda67351c04da552066017.camel%40j-davis.com
Reviewed-by: Greg Stark, Nathan Bossart, Noah Misch
2024-03-05 02:31:38 +01:00
|
|
|
AS 'SELECT $1 FROM public.do_analyze()';
|
2015-01-12 21:13:28 +01:00
|
|
|
CREATE INDEX ON vaccluster(wrap_do_analyze(i));
|
|
|
|
INSERT INTO vaccluster VALUES (1), (2);
|
|
|
|
ANALYZE vaccluster;
|
2015-01-08 04:33:58 +01:00
|
|
|
ERROR: ANALYZE cannot be executed from VACUUM or ANALYZE
|
|
|
|
CONTEXT: SQL function "do_analyze" statement 1
|
|
|
|
SQL function "wrap_do_analyze" statement 1
|
2019-06-19 00:51:04 +02:00
|
|
|
-- Test ANALYZE in transaction, where the transaction surrounding
|
|
|
|
-- analyze performed modifications. This tests for the bug at
|
|
|
|
-- https://postgr.es/m/c7988239-d42c-ddc4-41db-171b23b35e4f%40ssinger.info
|
|
|
|
-- (which hopefully is unlikely to be reintroduced), but also seems
|
|
|
|
-- independently worthwhile to cover.
|
|
|
|
INSERT INTO vactst SELECT generate_series(1, 300);
|
|
|
|
DELETE FROM vactst WHERE i % 7 = 0; -- delete a few rows outside
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO vactst SELECT generate_series(301, 400);
|
|
|
|
DELETE FROM vactst WHERE i % 5 <> 0; -- delete a few rows inside
|
|
|
|
ANALYZE vactst;
|
|
|
|
COMMIT;
|
2010-01-06 06:31:14 +01:00
|
|
|
VACUUM FULL pg_am;
|
|
|
|
VACUUM FULL pg_class;
|
|
|
|
VACUUM FULL pg_database;
|
|
|
|
VACUUM FULL vaccluster;
|
2015-01-08 04:33:58 +01:00
|
|
|
ERROR: ANALYZE cannot be executed from VACUUM or ANALYZE
|
|
|
|
CONTEXT: SQL function "do_analyze" statement 1
|
|
|
|
SQL function "wrap_do_analyze" statement 1
|
2015-01-12 21:13:28 +01:00
|
|
|
VACUUM FULL vactst;
|
2016-06-17 21:48:57 +02:00
|
|
|
VACUUM (DISABLE_PAGE_SKIPPING) vaccluster;
|
2020-01-20 03:27:49 +01:00
|
|
|
-- PARALLEL option
|
|
|
|
CREATE TABLE pvactst (i INT, a INT[], p POINT) with (autovacuum_enabled = off);
|
|
|
|
INSERT INTO pvactst SELECT i, array[1,2,3], point(i, i+1) FROM generate_series(1,1000) i;
|
|
|
|
CREATE INDEX btree_pvactst ON pvactst USING btree (i);
|
|
|
|
CREATE INDEX hash_pvactst ON pvactst USING hash (i);
|
|
|
|
CREATE INDEX brin_pvactst ON pvactst USING brin (i);
|
|
|
|
CREATE INDEX gin_pvactst ON pvactst USING gin (a);
|
|
|
|
CREATE INDEX gist_pvactst ON pvactst USING gist (p);
|
|
|
|
CREATE INDEX spgist_pvactst ON pvactst USING spgist (p);
|
|
|
|
-- VACUUM invokes parallel index cleanup
|
|
|
|
SET min_parallel_index_scan_size to 0;
|
|
|
|
VACUUM (PARALLEL 2) pvactst;
|
|
|
|
-- VACUUM invokes parallel bulk-deletion
|
|
|
|
UPDATE pvactst SET i = i WHERE i < 1000;
|
|
|
|
VACUUM (PARALLEL 2) pvactst;
|
|
|
|
UPDATE pvactst SET i = i WHERE i < 1000;
|
|
|
|
VACUUM (PARALLEL 0) pvactst; -- disable parallel vacuum
|
|
|
|
VACUUM (PARALLEL -1) pvactst; -- error
|
2021-05-25 05:56:53 +02:00
|
|
|
ERROR: parallel workers for vacuum must be between 0 and 1024
|
2020-01-20 03:27:49 +01:00
|
|
|
LINE 1: VACUUM (PARALLEL -1) pvactst;
|
|
|
|
^
|
|
|
|
VACUUM (PARALLEL 2, INDEX_CLEANUP FALSE) pvactst;
|
|
|
|
VACUUM (PARALLEL 2, FULL TRUE) pvactst; -- error, cannot use both PARALLEL and FULL
|
2020-04-16 07:14:03 +02:00
|
|
|
ERROR: VACUUM FULL cannot be performed in parallel
|
2020-01-20 03:27:49 +01:00
|
|
|
VACUUM (PARALLEL) pvactst; -- error, cannot use PARALLEL option without parallel degree
|
|
|
|
ERROR: parallel option requires a value between 0 and 1024
|
|
|
|
LINE 1: VACUUM (PARALLEL) pvactst;
|
|
|
|
^
|
2020-04-16 07:14:03 +02:00
|
|
|
-- Test different combinations of parallel and full options for temporary tables
|
2020-01-20 03:27:49 +01:00
|
|
|
CREATE TEMPORARY TABLE tmp (a int PRIMARY KEY);
|
|
|
|
CREATE INDEX tmp_idx1 ON tmp (a);
|
2020-04-16 07:14:03 +02:00
|
|
|
VACUUM (PARALLEL 1, FULL FALSE) tmp; -- parallel vacuum disabled for temp tables
|
2020-01-20 03:27:49 +01:00
|
|
|
WARNING: disabling parallel option of vacuum on "tmp" --- cannot vacuum temporary tables in parallel
|
2020-04-16 07:14:03 +02:00
|
|
|
VACUUM (PARALLEL 0, FULL TRUE) tmp; -- can specify parallel disabled (even though that's implied by FULL)
|
2020-01-20 03:27:49 +01:00
|
|
|
RESET min_parallel_index_scan_size;
|
|
|
|
DROP TABLE pvactst;
|
Allow VACUUM to be run with index cleanup disabled.
This commit adds a new reloption, vacuum_index_cleanup, which
controls whether index cleanup is performed for a particular
relation by default. It also adds a new option to the VACUUM
command, INDEX_CLEANUP, which can be used to override the
reloption. If neither the reloption nor the VACUUM option is
used, the default is true, as before.
Masahiko Sawada, reviewed and tested by Nathan Bossart, Alvaro
Herrera, Kyotaro Horiguchi, Darafei Praliaskouski, and me.
The wording of the documentation is mostly due to me.
Discussion: http://postgr.es/m/CAD21AoAt5R3DNUZSjOoXDUY=naYPUOuffVsRzuTYMz29yLzQCA@mail.gmail.com
2019-04-04 20:58:53 +02:00
|
|
|
-- INDEX_CLEANUP option
|
2019-06-25 02:09:27 +02:00
|
|
|
CREATE TABLE no_index_cleanup (i INT PRIMARY KEY, t TEXT);
|
|
|
|
-- Use uncompressed data stored in toast.
|
|
|
|
CREATE INDEX no_index_cleanup_idx ON no_index_cleanup(t);
|
|
|
|
ALTER TABLE no_index_cleanup ALTER COLUMN t SET STORAGE EXTERNAL;
|
|
|
|
INSERT INTO no_index_cleanup(i, t) VALUES (generate_series(1,30),
|
2020-04-09 14:10:01 +02:00
|
|
|
repeat('1234567890',269));
|
Allow VACUUM to be run with index cleanup disabled.
This commit adds a new reloption, vacuum_index_cleanup, which
controls whether index cleanup is performed for a particular
relation by default. It also adds a new option to the VACUUM
command, INDEX_CLEANUP, which can be used to override the
reloption. If neither the reloption nor the VACUUM option is
used, the default is true, as before.
Masahiko Sawada, reviewed and tested by Nathan Bossart, Alvaro
Herrera, Kyotaro Horiguchi, Darafei Praliaskouski, and me.
The wording of the documentation is mostly due to me.
Discussion: http://postgr.es/m/CAD21AoAt5R3DNUZSjOoXDUY=naYPUOuffVsRzuTYMz29yLzQCA@mail.gmail.com
2019-04-04 20:58:53 +02:00
|
|
|
-- index cleanup option is ignored if VACUUM FULL
|
|
|
|
VACUUM (INDEX_CLEANUP TRUE, FULL TRUE) no_index_cleanup;
|
|
|
|
VACUUM (FULL TRUE) no_index_cleanup;
|
2019-06-25 02:09:27 +02:00
|
|
|
-- Toast inherits the value from its parent table.
|
|
|
|
ALTER TABLE no_index_cleanup SET (vacuum_index_cleanup = false);
|
|
|
|
DELETE FROM no_index_cleanup WHERE i < 15;
|
|
|
|
-- Nothing is cleaned up.
|
|
|
|
VACUUM no_index_cleanup;
|
|
|
|
-- Both parent relation and toast are cleaned up.
|
|
|
|
ALTER TABLE no_index_cleanup SET (vacuum_index_cleanup = true);
|
|
|
|
VACUUM no_index_cleanup;
|
2021-06-19 05:04:07 +02:00
|
|
|
ALTER TABLE no_index_cleanup SET (vacuum_index_cleanup = auto);
|
|
|
|
VACUUM no_index_cleanup;
|
2019-06-25 02:09:27 +02:00
|
|
|
-- Parameter is set for both the parent table and its toast relation.
|
|
|
|
INSERT INTO no_index_cleanup(i, t) VALUES (generate_series(31,60),
|
2020-04-09 14:10:01 +02:00
|
|
|
repeat('1234567890',269));
|
2019-06-25 02:09:27 +02:00
|
|
|
DELETE FROM no_index_cleanup WHERE i < 45;
|
|
|
|
-- Only toast index is cleaned up.
|
2021-06-19 05:04:07 +02:00
|
|
|
ALTER TABLE no_index_cleanup SET (vacuum_index_cleanup = off,
|
|
|
|
toast.vacuum_index_cleanup = yes);
|
2019-06-25 02:09:27 +02:00
|
|
|
VACUUM no_index_cleanup;
|
|
|
|
-- Only parent is cleaned up.
|
|
|
|
ALTER TABLE no_index_cleanup SET (vacuum_index_cleanup = true,
|
|
|
|
toast.vacuum_index_cleanup = false);
|
|
|
|
VACUUM no_index_cleanup;
|
|
|
|
-- Test some extra relations.
|
|
|
|
VACUUM (INDEX_CLEANUP FALSE) vaccluster;
|
2021-06-19 05:04:07 +02:00
|
|
|
VACUUM (INDEX_CLEANUP AUTO) vactst; -- index cleanup option is ignored if no indexes
|
2019-06-25 02:09:27 +02:00
|
|
|
VACUUM (INDEX_CLEANUP FALSE, FREEZE TRUE) vaccluster;
|
2019-05-07 19:10:33 +02:00
|
|
|
-- TRUNCATE option
|
2022-03-23 02:31:18 +01:00
|
|
|
CREATE TEMP TABLE vac_truncate_test(i INT NOT NULL, j text)
|
2019-05-07 19:10:33 +02:00
|
|
|
WITH (vacuum_truncate=true, autovacuum_enabled=false);
|
|
|
|
INSERT INTO vac_truncate_test VALUES (1, NULL), (NULL, NULL);
|
2020-01-28 03:18:10 +01:00
|
|
|
ERROR: null value in column "i" of relation "vac_truncate_test" violates not-null constraint
|
2019-05-07 19:10:33 +02:00
|
|
|
DETAIL: Failing row contains (null, null).
|
2022-03-23 02:31:18 +01:00
|
|
|
VACUUM (TRUNCATE FALSE, DISABLE_PAGE_SKIPPING) vac_truncate_test;
|
2019-05-07 19:10:33 +02:00
|
|
|
SELECT pg_relation_size('vac_truncate_test') > 0;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2022-03-23 02:31:18 +01:00
|
|
|
VACUUM (DISABLE_PAGE_SKIPPING) vac_truncate_test;
|
2019-05-07 19:10:33 +02:00
|
|
|
SELECT pg_relation_size('vac_truncate_test') = 0;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
VACUUM (TRUNCATE FALSE, FULL TRUE) vac_truncate_test;
|
|
|
|
DROP TABLE vac_truncate_test;
|
2017-03-07 17:24:51 +01:00
|
|
|
-- partitioned table
|
|
|
|
CREATE TABLE vacparted (a int, b char) PARTITION BY LIST (a);
|
|
|
|
CREATE TABLE vacparted1 PARTITION OF vacparted FOR VALUES IN (1);
|
|
|
|
INSERT INTO vacparted VALUES (1, 'a');
|
|
|
|
UPDATE vacparted SET b = 'b';
|
|
|
|
VACUUM (ANALYZE) vacparted;
|
|
|
|
VACUUM (FULL) vacparted;
|
|
|
|
VACUUM (FREEZE) vacparted;
|
2017-09-22 00:13:11 +02:00
|
|
|
-- check behavior with duplicate column mentions
|
|
|
|
VACUUM ANALYZE vacparted(a,b,a);
|
2017-09-26 21:25:56 +02:00
|
|
|
ERROR: column "a" of relation "vacparted" appears more than once
|
2017-09-22 00:13:11 +02:00
|
|
|
ANALYZE vacparted(a,b,b);
|
2017-09-26 21:25:56 +02:00
|
|
|
ERROR: column "b" of relation "vacparted" appears more than once
|
2021-07-01 18:56:30 +02:00
|
|
|
-- partitioned table with index
|
|
|
|
CREATE TABLE vacparted_i (a int primary key, b varchar(100))
|
|
|
|
PARTITION BY HASH (a);
|
|
|
|
CREATE TABLE vacparted_i1 PARTITION OF vacparted_i
|
|
|
|
FOR VALUES WITH (MODULUS 2, REMAINDER 0);
|
|
|
|
CREATE TABLE vacparted_i2 PARTITION OF vacparted_i
|
|
|
|
FOR VALUES WITH (MODULUS 2, REMAINDER 1);
|
|
|
|
INSERT INTO vacparted_i SELECT i, 'test_'|| i from generate_series(1,10) i;
|
|
|
|
VACUUM (ANALYZE) vacparted_i;
|
|
|
|
VACUUM (FULL) vacparted_i;
|
|
|
|
VACUUM (FREEZE) vacparted_i;
|
|
|
|
SELECT relname, relhasindex FROM pg_class
|
|
|
|
WHERE relname LIKE 'vacparted_i%' AND relkind IN ('p','r')
|
|
|
|
ORDER BY relname;
|
|
|
|
relname | relhasindex
|
|
|
|
--------------+-------------
|
|
|
|
vacparted_i | t
|
|
|
|
vacparted_i1 | t
|
|
|
|
vacparted_i2 | t
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
DROP TABLE vacparted_i;
|
2017-10-04 00:53:44 +02:00
|
|
|
-- multiple tables specified
|
|
|
|
VACUUM vaccluster, vactst;
|
|
|
|
VACUUM vacparted, does_not_exist;
|
|
|
|
ERROR: relation "does_not_exist" does not exist
|
|
|
|
VACUUM (FREEZE) vacparted, vaccluster, vactst;
|
|
|
|
VACUUM (FREEZE) does_not_exist, vaccluster;
|
|
|
|
ERROR: relation "does_not_exist" does not exist
|
|
|
|
VACUUM ANALYZE vactst, vacparted (a);
|
|
|
|
VACUUM ANALYZE vactst (does_not_exist), vacparted (b);
|
|
|
|
ERROR: column "does_not_exist" of relation "vactst" does not exist
|
|
|
|
VACUUM FULL vacparted, vactst;
|
|
|
|
VACUUM FULL vactst, vacparted (a, b), vaccluster (i);
|
|
|
|
ERROR: ANALYZE option must be specified when a column list is provided
|
|
|
|
ANALYZE vactst, vacparted;
|
|
|
|
ANALYZE vacparted (b), vactst;
|
|
|
|
ANALYZE vactst, does_not_exist, vacparted;
|
|
|
|
ERROR: relation "does_not_exist" does not exist
|
|
|
|
ANALYZE vactst (i), vacparted (does_not_exist);
|
|
|
|
ERROR: column "does_not_exist" of relation "vacparted" does not exist
|
Fix "ANALYZE t, t" inside a transaction block.
This failed with either "tuple already updated by self" or "duplicate
key value violates unique constraint", depending on whether the table
had previously been analyzed or not. The reason is that ANALYZE tried
to insert or update the same pg_statistic rows twice, and there was no
CommandCounterIncrement between. So add one. The same case works fine
outside a transaction block, because then there's a whole transaction
boundary between, as a consequence of the way VACUUM works.
This issue has been latent all along, but the problem was unreachable
before commit 11d8d72c2 added the ability to specify multiple tables
in ANALYZE. We could, perhaps, alternatively fix it by adding code to
de-duplicate the list of VacuumRelations --- but that would add a
lot of overhead to work around dumb commands, so it's not attractive.
Per bug #15946 from Yaroslav Schekin. Back-patch to v11.
(Note: in v11 I also back-patched the test added by commit 23224563d;
otherwise the problem doesn't manifest in the test I added, because
"vactst" is empty when the tests for multiple ANALYZE targets are
reached. That seems like not a very good thing anyway, so I did this
rather than rethinking the choice of test case.)
Discussion: https://postgr.es/m/15946-5c7570a2884a26cf@postgresql.org
2019-08-10 17:30:11 +02:00
|
|
|
ANALYZE vactst, vactst;
|
|
|
|
BEGIN; -- ANALYZE behaves differently inside a transaction block
|
|
|
|
ANALYZE vactst, vactst;
|
|
|
|
COMMIT;
|
2018-03-06 01:21:05 +01:00
|
|
|
-- parenthesized syntax for ANALYZE
|
|
|
|
ANALYZE (VERBOSE) does_not_exist;
|
|
|
|
ERROR: relation "does_not_exist" does not exist
|
2018-10-04 02:00:33 +02:00
|
|
|
ANALYZE (nonexistent-arg) does_not_exist;
|
2019-05-20 18:36:06 +02:00
|
|
|
ERROR: syntax error at or near "arg"
|
2018-10-04 02:00:33 +02:00
|
|
|
LINE 1: ANALYZE (nonexistent-arg) does_not_exist;
|
2019-05-20 18:36:06 +02:00
|
|
|
^
|
2019-03-18 20:14:52 +01:00
|
|
|
ANALYZE (nonexistentarg) does_not_exit;
|
|
|
|
ERROR: unrecognized ANALYZE option "nonexistentarg"
|
|
|
|
LINE 1: ANALYZE (nonexistentarg) does_not_exit;
|
2018-03-06 01:21:05 +01:00
|
|
|
^
|
2018-10-04 02:00:33 +02:00
|
|
|
-- ensure argument order independence, and that SKIP_LOCKED on non-existing
|
2019-11-16 07:23:12 +01:00
|
|
|
-- relation still errors out. Suppress WARNING messages caused by concurrent
|
|
|
|
-- autovacuums.
|
|
|
|
SET client_min_messages TO 'ERROR';
|
2018-10-04 02:00:33 +02:00
|
|
|
ANALYZE (SKIP_LOCKED, VERBOSE) does_not_exist;
|
|
|
|
ERROR: relation "does_not_exist" does not exist
|
|
|
|
ANALYZE (VERBOSE, SKIP_LOCKED) does_not_exist;
|
|
|
|
ERROR: relation "does_not_exist" does not exist
|
|
|
|
-- SKIP_LOCKED option
|
|
|
|
VACUUM (SKIP_LOCKED) vactst;
|
|
|
|
VACUUM (SKIP_LOCKED, FULL) vactst;
|
|
|
|
ANALYZE (SKIP_LOCKED) vactst;
|
2019-11-16 07:23:12 +01:00
|
|
|
RESET client_min_messages;
|
Don't to predicate lock for analyze scans, refactor scan option passing.
Before this commit, when ANALYZE was run on a table and serializable
was used (either by virtue of an explicit BEGIN TRANSACTION ISOLATION
LEVEL SERIALIZABLE, or default_transaction_isolation being set to
serializable) a null pointer dereference lead to a crash.
The analyze scan doesn't need a snapshot (nor predicate locking), but
before this commit a scan only contained information about being a
bitmap or sample scan.
Refactor the option passing to the scan_begin callback to use a
bitmask instead. Alternatively we could have added a new boolean
parameter, but that seems harder to read. Even before this issue
various people (Heikki, Tom, Robert) suggested doing so.
These changes don't change the scan APIs outside of tableam. The flags
argument could be exposed, it's not necessary to fix this
problem. Also the wrapper table_beginscan* functions encapsulate most
of that complexity.
After these changes fixing the bug is trivial, just don't acquire
predicate lock for analyze style scans. That was already done for
bitmap heap scans. Add an assert that a snapshot is passed when
acquiring the predicate lock, so this kind of bug doesn't require
running with serializable.
Also add a comment about sample scans currently requiring predicate
locking the entire relation, that previously wasn't remarked upon.
Reported-By: Joe Wildish
Author: Andres Freund
Discussion:
https://postgr.es/m/4EA80A20-E9BF-49F1-9F01-5B66CAB21453@elusive.cx
https://postgr.es/m/20190411164947.nkii4gaeilt4bui7@alap3.anarazel.de
https://postgr.es/m/20190518203102.g7peu2fianukjuxm@alap3.anarazel.de
2019-05-20 00:10:28 +02:00
|
|
|
-- ensure VACUUM and ANALYZE don't have a problem with serializable
|
|
|
|
SET default_transaction_isolation = serializable;
|
|
|
|
VACUUM vactst;
|
|
|
|
ANALYZE vactst;
|
|
|
|
RESET default_transaction_isolation;
|
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
|
|
|
ANALYZE vactst;
|
|
|
|
COMMIT;
|
2021-02-09 06:13:57 +01:00
|
|
|
-- PROCESS_TOAST option
|
2023-03-06 07:40:56 +01:00
|
|
|
CREATE TABLE vac_option_tab (a INT, t TEXT);
|
|
|
|
INSERT INTO vac_option_tab SELECT a, 't' || a FROM generate_series(1, 10) AS a;
|
|
|
|
ALTER TABLE vac_option_tab ALTER COLUMN t SET STORAGE EXTERNAL;
|
|
|
|
-- Check the number of vacuums done on table vac_option_tab and on its
|
2023-03-06 08:41:05 +01:00
|
|
|
-- toast relation, to check that PROCESS_TOAST and PROCESS_MAIN work on
|
|
|
|
-- what they should.
|
2023-03-06 07:40:56 +01:00
|
|
|
CREATE VIEW vac_option_tab_counts AS
|
|
|
|
SELECT CASE WHEN c.relname IS NULL
|
|
|
|
THEN 'main' ELSE 'toast' END as rel,
|
|
|
|
s.vacuum_count
|
|
|
|
FROM pg_stat_all_tables s
|
|
|
|
LEFT JOIN pg_class c ON s.relid = c.reltoastrelid
|
|
|
|
WHERE c.relname = 'vac_option_tab' OR s.relname = 'vac_option_tab'
|
|
|
|
ORDER BY rel;
|
|
|
|
VACUUM (PROCESS_TOAST TRUE) vac_option_tab;
|
|
|
|
SELECT * FROM vac_option_tab_counts;
|
|
|
|
rel | vacuum_count
|
|
|
|
-------+--------------
|
|
|
|
main | 1
|
|
|
|
toast | 1
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
VACUUM (PROCESS_TOAST FALSE) vac_option_tab;
|
|
|
|
SELECT * FROM vac_option_tab_counts;
|
|
|
|
rel | vacuum_count
|
|
|
|
-------+--------------
|
|
|
|
main | 2
|
|
|
|
toast | 1
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
VACUUM (PROCESS_TOAST FALSE, FULL) vac_option_tab; -- error
|
2021-02-09 06:13:57 +01:00
|
|
|
ERROR: PROCESS_TOAST required with VACUUM FULL
|
2023-03-06 08:41:05 +01:00
|
|
|
-- PROCESS_MAIN option
|
|
|
|
-- Only the toast table is processed.
|
|
|
|
VACUUM (PROCESS_MAIN FALSE) vac_option_tab;
|
|
|
|
SELECT * FROM vac_option_tab_counts;
|
|
|
|
rel | vacuum_count
|
|
|
|
-------+--------------
|
|
|
|
main | 2
|
|
|
|
toast | 2
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- Nothing is processed.
|
|
|
|
VACUUM (PROCESS_MAIN FALSE, PROCESS_TOAST FALSE) vac_option_tab;
|
|
|
|
SELECT * FROM vac_option_tab_counts;
|
|
|
|
rel | vacuum_count
|
|
|
|
-------+--------------
|
|
|
|
main | 2
|
|
|
|
toast | 2
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- Check if the filenodes nodes have been updated as wanted after FULL.
|
|
|
|
SELECT relfilenode AS main_filenode FROM pg_class
|
|
|
|
WHERE relname = 'vac_option_tab' \gset
|
|
|
|
SELECT t.relfilenode AS toast_filenode FROM pg_class c, pg_class t
|
|
|
|
WHERE c.reltoastrelid = t.oid AND c.relname = 'vac_option_tab' \gset
|
|
|
|
-- Only the toast relation is processed.
|
|
|
|
VACUUM (PROCESS_MAIN FALSE, FULL) vac_option_tab;
|
|
|
|
SELECT relfilenode = :main_filenode AS is_same_main_filenode
|
|
|
|
FROM pg_class WHERE relname = 'vac_option_tab';
|
|
|
|
is_same_main_filenode
|
|
|
|
-----------------------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT t.relfilenode = :toast_filenode AS is_same_toast_filenode
|
|
|
|
FROM pg_class c, pg_class t
|
|
|
|
WHERE c.reltoastrelid = t.oid AND c.relname = 'vac_option_tab';
|
|
|
|
is_same_toast_filenode
|
|
|
|
------------------------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2023-04-07 01:40:31 +02:00
|
|
|
-- BUFFER_USAGE_LIMIT option
|
|
|
|
VACUUM (BUFFER_USAGE_LIMIT '512 kB') vac_option_tab;
|
|
|
|
ANALYZE (BUFFER_USAGE_LIMIT '512 kB') vac_option_tab;
|
|
|
|
-- try disabling the buffer usage limit
|
|
|
|
VACUUM (BUFFER_USAGE_LIMIT 0) vac_option_tab;
|
|
|
|
ANALYZE (BUFFER_USAGE_LIMIT 0) vac_option_tab;
|
|
|
|
-- value exceeds max size error
|
|
|
|
VACUUM (BUFFER_USAGE_LIMIT 16777220) vac_option_tab;
|
2023-04-11 09:36:34 +02:00
|
|
|
ERROR: BUFFER_USAGE_LIMIT option must be 0 or between 128 kB and 16777216 kB
|
2023-04-07 01:40:31 +02:00
|
|
|
-- value is less than min size error
|
|
|
|
VACUUM (BUFFER_USAGE_LIMIT 120) vac_option_tab;
|
2023-04-11 09:36:34 +02:00
|
|
|
ERROR: BUFFER_USAGE_LIMIT option must be 0 or between 128 kB and 16777216 kB
|
2023-04-07 01:40:31 +02:00
|
|
|
-- integer overflow error
|
|
|
|
VACUUM (BUFFER_USAGE_LIMIT 10000000000) vac_option_tab;
|
2023-04-11 09:36:34 +02:00
|
|
|
ERROR: BUFFER_USAGE_LIMIT option must be 0 or between 128 kB and 16777216 kB
|
2023-04-07 01:40:31 +02:00
|
|
|
HINT: Value exceeds integer range.
|
|
|
|
-- incompatible with VACUUM FULL error
|
|
|
|
VACUUM (BUFFER_USAGE_LIMIT '512 kB', FULL) vac_option_tab;
|
|
|
|
ERROR: BUFFER_USAGE_LIMIT cannot be specified for VACUUM FULL
|
2023-01-06 20:17:25 +01:00
|
|
|
-- SKIP_DATABASE_STATS option
|
|
|
|
VACUUM (SKIP_DATABASE_STATS) vactst;
|
|
|
|
-- ONLY_DATABASE_STATS option
|
|
|
|
VACUUM (ONLY_DATABASE_STATS);
|
|
|
|
VACUUM (ONLY_DATABASE_STATS) vactst; -- error
|
|
|
|
ERROR: ONLY_DATABASE_STATS cannot be specified with a list of tables
|
2023-03-06 07:40:56 +01:00
|
|
|
DROP VIEW vac_option_tab_counts;
|
|
|
|
DROP TABLE vac_option_tab;
|
2017-10-04 00:53:44 +02:00
|
|
|
DROP TABLE vaccluster;
|
|
|
|
DROP TABLE vactst;
|
2017-03-07 17:24:51 +01:00
|
|
|
DROP TABLE vacparted;
|
Allow VACUUM to be run with index cleanup disabled.
This commit adds a new reloption, vacuum_index_cleanup, which
controls whether index cleanup is performed for a particular
relation by default. It also adds a new option to the VACUUM
command, INDEX_CLEANUP, which can be used to override the
reloption. If neither the reloption nor the VACUUM option is
used, the default is true, as before.
Masahiko Sawada, reviewed and tested by Nathan Bossart, Alvaro
Herrera, Kyotaro Horiguchi, Darafei Praliaskouski, and me.
The wording of the documentation is mostly due to me.
Discussion: http://postgr.es/m/CAD21AoAt5R3DNUZSjOoXDUY=naYPUOuffVsRzuTYMz29yLzQCA@mail.gmail.com
2019-04-04 20:58:53 +02:00
|
|
|
DROP TABLE no_index_cleanup;
|
2018-08-22 02:41:37 +02:00
|
|
|
-- relation ownership, WARNING logs generated as all are skipped.
|
|
|
|
CREATE TABLE vacowned (a int);
|
2018-08-24 02:15:08 +02:00
|
|
|
CREATE TABLE vacowned_parted (a int) PARTITION BY LIST (a);
|
|
|
|
CREATE TABLE vacowned_part1 PARTITION OF vacowned_parted FOR VALUES IN (1);
|
|
|
|
CREATE TABLE vacowned_part2 PARTITION OF vacowned_parted FOR VALUES IN (2);
|
2018-08-22 02:41:37 +02:00
|
|
|
CREATE ROLE regress_vacuum;
|
|
|
|
SET ROLE regress_vacuum;
|
|
|
|
-- Simple table
|
|
|
|
VACUUM vacowned;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned", skipping it
|
2018-08-22 02:41:37 +02:00
|
|
|
ANALYZE vacowned;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to analyze "vacowned", skipping it
|
2018-08-22 02:41:37 +02:00
|
|
|
VACUUM (ANALYZE) vacowned;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned", skipping it
|
2018-08-22 02:41:37 +02:00
|
|
|
-- Catalog
|
|
|
|
VACUUM pg_catalog.pg_class;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "pg_class", skipping it
|
2018-08-22 02:41:37 +02:00
|
|
|
ANALYZE pg_catalog.pg_class;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to analyze "pg_class", skipping it
|
2018-08-22 02:41:37 +02:00
|
|
|
VACUUM (ANALYZE) pg_catalog.pg_class;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "pg_class", skipping it
|
2018-08-22 02:41:37 +02:00
|
|
|
-- Shared catalog
|
|
|
|
VACUUM pg_catalog.pg_authid;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "pg_authid", skipping it
|
2018-08-22 02:41:37 +02:00
|
|
|
ANALYZE pg_catalog.pg_authid;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to analyze "pg_authid", skipping it
|
2018-08-22 02:41:37 +02:00
|
|
|
VACUUM (ANALYZE) pg_catalog.pg_authid;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "pg_authid", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
-- Partitioned table and its partitions, nothing owned by other user.
|
|
|
|
-- Relations are not listed in a single command to test ownership
|
|
|
|
-- independently.
|
|
|
|
VACUUM vacowned_parted;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_parted", skipping it
|
|
|
|
WARNING: permission denied to vacuum "vacowned_part1", skipping it
|
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM vacowned_part1;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part1", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM vacowned_part2;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_parted;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to analyze "vacowned_parted", skipping it
|
|
|
|
WARNING: permission denied to analyze "vacowned_part1", skipping it
|
|
|
|
WARNING: permission denied to analyze "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_part1;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to analyze "vacowned_part1", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_part2;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to analyze "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_parted;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_parted", skipping it
|
|
|
|
WARNING: permission denied to vacuum "vacowned_part1", skipping it
|
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_part1;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part1", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_part2;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
RESET ROLE;
|
|
|
|
-- Partitioned table and one partition owned by other user.
|
|
|
|
ALTER TABLE vacowned_parted OWNER TO regress_vacuum;
|
|
|
|
ALTER TABLE vacowned_part1 OWNER TO regress_vacuum;
|
|
|
|
SET ROLE regress_vacuum;
|
|
|
|
VACUUM vacowned_parted;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM vacowned_part1;
|
|
|
|
VACUUM vacowned_part2;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_parted;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to analyze "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_part1;
|
|
|
|
ANALYZE vacowned_part2;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to analyze "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_parted;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_part1;
|
|
|
|
VACUUM (ANALYZE) vacowned_part2;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
RESET ROLE;
|
|
|
|
-- Only one partition owned by other user.
|
|
|
|
ALTER TABLE vacowned_parted OWNER TO CURRENT_USER;
|
|
|
|
SET ROLE regress_vacuum;
|
|
|
|
VACUUM vacowned_parted;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_parted", skipping it
|
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM vacowned_part1;
|
|
|
|
VACUUM vacowned_part2;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_parted;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to analyze "vacowned_parted", skipping it
|
|
|
|
WARNING: permission denied to analyze "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_part1;
|
|
|
|
ANALYZE vacowned_part2;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to analyze "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_parted;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_parted", skipping it
|
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_part1;
|
|
|
|
VACUUM (ANALYZE) vacowned_part2;
|
2022-11-23 20:41:30 +01:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
RESET ROLE;
|
|
|
|
-- Only partitioned table owned by other user.
|
|
|
|
ALTER TABLE vacowned_parted OWNER TO regress_vacuum;
|
|
|
|
ALTER TABLE vacowned_part1 OWNER TO CURRENT_USER;
|
|
|
|
SET ROLE regress_vacuum;
|
|
|
|
VACUUM vacowned_parted;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part1", skipping it
|
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM vacowned_part1;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part1", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM vacowned_part2;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_parted;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to analyze "vacowned_part1", skipping it
|
|
|
|
WARNING: permission denied to analyze "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_part1;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to analyze "vacowned_part1", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
ANALYZE vacowned_part2;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to analyze "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_parted;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part1", skipping it
|
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_part1;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part1", skipping it
|
2018-08-24 02:15:08 +02:00
|
|
|
VACUUM (ANALYZE) vacowned_part2;
|
Fix cache lookup hazards introduced by ff9618e82a.
ff9618e82a introduced has_partition_ancestor_privs(), which is used
to check whether a user has MAINTAIN on any partition ancestors.
This involves syscache lookups, and presently this function does
not take any relation locks, so it is likely subject to the same
kind of cache lookup failures that were fixed by 19de0ab23c.
To fix this problem, this commit partially reverts ff9618e82a.
Specifically, it removes the partition-related changes, including
the has_partition_ancestor_privs() function mentioned above. This
means that MAINTAIN on a partitioned table is no longer sufficient
to perform maintenance commands on its partitions. This is more
like how privileges for maintenance commands work on supported
versions. Privileges are checked for each partition, so a command
that flows down to all partitions might refuse to process them
(e.g., if the current user doesn't have MAINTAIN on the partition).
In passing, adjust a few related comments and error messages, and
add a test for the privilege checks for CLUSTER on a partitioned
table.
Reviewed-by: Michael Paquier, Jeff Davis
Discussion: https://postgr.es/m/20230613211246.GA219055%40nathanxps13
2023-06-23 00:48:20 +02:00
|
|
|
WARNING: permission denied to vacuum "vacowned_part2", skipping it
|
2018-08-22 02:41:37 +02:00
|
|
|
RESET ROLE;
|
|
|
|
DROP TABLE vacowned;
|
2018-08-24 02:15:08 +02:00
|
|
|
DROP TABLE vacowned_parted;
|
2018-08-22 02:41:37 +02:00
|
|
|
DROP ROLE regress_vacuum;
|