rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/test/regress/expected/vacuum.out

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

511 lines
20 KiB
Plaintext
Raw Normal View History

Add new vacuum regression test files.
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;
Provide a parenthesized-options syntax for VACUUM, analogous to that recently adopted for EXPLAIN. This will allow additional options to be implemented in future without having to make them fully-reserved keywords. The old syntax remains available for existing options, however. Itagaki Takahiro
2009-11-16 22:32:07 +01:00
VACUUM (FULL) vactst;
Add new vacuum regression test files.
2002-07-20 06:58:14 +02:00
DELETE FROM vactst;
SELECT * FROM vactst;
i
---
(0 rows)
Provide a parenthesized-options syntax for VACUUM, analogous to that recently adopted for EXPLAIN. This will allow additional options to be implemented in future without having to make them fully-reserved keywords. The old syntax remains available for existing options, however. Itagaki Takahiro
2009-11-16 22:32:07 +01:00
VACUUM (FULL, FREEZE) vactst;
Remove old-style VACUUM FULL (which was known for a little while as VACUUM FULL INPLACE), along with a boatload of subsidiary code and complexity. Per discussion, the use case for this method of vacuuming is no longer large enough to justify maintaining it; not to mention that we don't wish to invest the work that would be needed to make it play nicely with Hot Standby. Aside from the code directly related to old-style VACUUM FULL, this commit removes support for certain WAL record types that could only be generated within VACUUM FULL, redirect-pointer removal in heap_page_prune, and nontransactional generation of cache invalidation sinval messages (the last being the sticking point for Hot Standby). We still have to retain all code that copes with finding HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples. This can't be removed as long as we want to support in-place update from pre-9.0 databases.
2010-02-08 05:33:55 +01:00
VACUUM (ANALYZE, FULL) vactst;
Support rewritten-based full vacuum as VACUUM FULL. Traditional VACUUM FULL was renamed to VACUUM FULL INPLACE. Also added a new option -i, --inplace for vacuumdb to perform FULL INPLACE vacuuming. Since the new VACUUM FULL uses CLUSTER infrastructure, we cannot use it for system tables. VACUUM FULL for system tables always fall back into VACUUM FULL INPLACE silently. Itagaki Takahiro, reviewed by Jeff Davis and Simon Riggs.
2010-01-06 06:31:14 +01:00
CREATE TABLE vaccluster (i INT PRIMARY KEY);
ALTER TABLE vaccluster CLUSTER ON vaccluster_pkey;
CLUSTER vaccluster;
Reject ANALYZE commands during VACUUM FULL or another ANALYZE. vacuum()'s static variable handling makes it non-reentrant; an ensuing null pointer deference crashed the backend. Back-patch to 9.0 (all supported versions).
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()';
Avoid unexpected slowdown in vacuum regression test. I noticed the "vacuum" regression test taking really significantly longer than it used to on a slow machine. Investigation pointed the finger at commit e415b469b33ba328765e39fd62edcd28f30d9c3c, which added creation of an index using an extremely expensive index function. That function was evidently meant to be applied only twice ... but the test re-used an existing test table, which up till a couple lines before that had had over two thousand rows. Depending on timing of the concurrent regression tests, the intervening VACUUMs might have been unable to remove those recently-dead rows, and then the index build would need to create index entries for them too, leading to the wrap_do_analyze() function being executed 2000+ times not twice. Avoid this by using a different table that is guaranteed to have only the intended two rows in it. Back-patch to 9.0, like the commit that created the problem.
2015-01-12 21:13:28 +01:00
CREATE INDEX ON vaccluster(wrap_do_analyze(i));
INSERT INTO vaccluster VALUES (1), (2);
ANALYZE vaccluster;
Reject ANALYZE commands during VACUUM FULL or another ANALYZE. vacuum()'s static variable handling makes it non-reentrant; an ensuing null pointer deference crashed the backend. Back-patch to 9.0 (all supported versions).
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
Fix memory corruption/crash in ANALYZE. This fixes an embarrassing oversight I (Andres) made in 737a292b, namely missing two place where liverows/deadrows were used when converting those variables to pointers, leading to incrementing the pointer, rather than the value. It's not that actually that easy to trigger a crash: One needs tuples deleted by the current transaction, followed by a tuple deleted in another session, all in one page. Which is presumably why this hasn't been noticed before. Reported-By: Steve Singer Author: Steve Singer Discussion: https://postgr.es/m/c7988239-d42c-ddc4-41db-171b23b35e4f@ssinger.info
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;
Support rewritten-based full vacuum as VACUUM FULL. Traditional VACUUM FULL was renamed to VACUUM FULL INPLACE. Also added a new option -i, --inplace for vacuumdb to perform FULL INPLACE vacuuming. Since the new VACUUM FULL uses CLUSTER infrastructure, we cannot use it for system tables. VACUUM FULL for system tables always fall back into VACUUM FULL INPLACE silently. Itagaki Takahiro, reviewed by Jeff Davis and Simon Riggs.
2010-01-06 06:31:14 +01:00
VACUUM FULL pg_am;
VACUUM FULL pg_class;
VACUUM FULL pg_database;
VACUUM FULL vaccluster;
Reject ANALYZE commands during VACUUM FULL or another ANALYZE. vacuum()'s static variable handling makes it non-reentrant; an ensuing null pointer deference crashed the backend. Back-patch to 9.0 (all supported versions).
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
Avoid unexpected slowdown in vacuum regression test. I noticed the "vacuum" regression test taking really significantly longer than it used to on a slow machine. Investigation pointed the finger at commit e415b469b33ba328765e39fd62edcd28f30d9c3c, which added creation of an index using an extremely expensive index function. That function was evidently meant to be applied only twice ... but the test re-used an existing test table, which up till a couple lines before that had had over two thousand rows. Depending on timing of the concurrent regression tests, the intervening VACUUMs might have been unable to remove those recently-dead rows, and then the index build would need to create index entries for them too, leading to the wrap_do_analyze() function being executed 2000+ times not twice. Avoid this by using a different table that is guaranteed to have only the intended two rows in it. Back-patch to 9.0, like the commit that created the problem.
2015-01-12 21:13:28 +01:00
VACUUM FULL vactst;
Add VACUUM (DISABLE_PAGE_SKIPPING) for emergencies. If you really want to vacuum every single page in the relation, regardless of apparent visibility status or anything else, you can use this option. In previous releases, this behavior could be achieved using VACUUM (FREEZE), but because we can now recognize all-frozen pages as not needing to be frozen again, that no longer works. There should be no need for routine use of this option, but maybe bugs or disaster recovery will necessitate its use. Patch by me, reviewed by Andres Freund.
2016-06-17 21:48:57 +02:00
VACUUM (DISABLE_PAGE_SKIPPING) vaccluster;
Allow vacuum command to process indexes in parallel. This feature allows the vacuum to leverage multiple CPUs in order to process indexes. This enables us to perform index vacuuming and index cleanup with background workers. This adds a PARALLEL option to VACUUM command where the user can specify the number of workers that can be used to perform the command which is limited by the number of indexes on a table. Specifying zero as a number of workers will disable parallelism. This option can't be used with the FULL option. Each index is processed by at most one vacuum process. Therefore parallel vacuum can be used when the table has at least two indexes. The parallel degree is either specified by the user or determined based on the number of indexes that the table has, and further limited by max_parallel_maintenance_workers. The index can participate in parallel vacuum iff it's size is greater than min_parallel_index_scan_size. Author: Masahiko Sawada and Amit Kapila Reviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra, Mahendra Singh and Sergei Kornilov Tested-by: Mahendra Singh and Prabhat Sahu Discussion: https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com
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
Improve docs and error messages for parallel vacuum. The error messages, docs, and one of the options were using 'parallel degree' to indicate parallelism used by vacuum command. We normally use 'parallel workers' at other places so change it for parallel vacuum accordingly. Author: Bharath Rupireddy Reviewed-by: Dilip Kumar, Amit Kapila Backpatch-through: 13 Discussion: https://postgr.es/m/CALj2ACWz=PYrrFXVsEKb9J1aiX4raA+UBe02hdRp_zqDkrWUiw@mail.gmail.com
2021-05-25 05:56:53 +02:00
ERROR: parallel workers for vacuum must be between 0 and 1024
Allow vacuum command to process indexes in parallel. This feature allows the vacuum to leverage multiple CPUs in order to process indexes. This enables us to perform index vacuuming and index cleanup with background workers. This adds a PARALLEL option to VACUUM command where the user can specify the number of workers that can be used to perform the command which is limited by the number of indexes on a table. Specifying zero as a number of workers will disable parallelism. This option can't be used with the FULL option. Each index is processed by at most one vacuum process. Therefore parallel vacuum can be used when the table has at least two indexes. The parallel degree is either specified by the user or determined based on the number of indexes that the table has, and further limited by max_parallel_maintenance_workers. The index can participate in parallel vacuum iff it's size is greater than min_parallel_index_scan_size. Author: Masahiko Sawada and Amit Kapila Reviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra, Mahendra Singh and Sergei Kornilov Tested-by: Mahendra Singh and Prabhat Sahu Discussion: https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com
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
Fix the usage of parallel and full options of vacuum command. Earlier we were inconsistent in allowing the usage of parallel and full options. Change it such that we disallow them only when they are combined in a way that we don't support. In passing, improve the comments in some of the existing tests of parallel vacuum. Reported-by: Tushar Ahuja Author: Justin Pryzby, Amit Kapila Reviewed-by: Sawada Masahiko, Michael Paquier, Mahendra Singh Thalor and Amit Kapila Discussion: https://postgr.es/m/58c8d171-e665-6fa3-a9d3-d9423b694dae%40enterprisedb.com
2020-04-16 07:14:03 +02:00
ERROR: VACUUM FULL cannot be performed in parallel
Allow vacuum command to process indexes in parallel. This feature allows the vacuum to leverage multiple CPUs in order to process indexes. This enables us to perform index vacuuming and index cleanup with background workers. This adds a PARALLEL option to VACUUM command where the user can specify the number of workers that can be used to perform the command which is limited by the number of indexes on a table. Specifying zero as a number of workers will disable parallelism. This option can't be used with the FULL option. Each index is processed by at most one vacuum process. Therefore parallel vacuum can be used when the table has at least two indexes. The parallel degree is either specified by the user or determined based on the number of indexes that the table has, and further limited by max_parallel_maintenance_workers. The index can participate in parallel vacuum iff it's size is greater than min_parallel_index_scan_size. Author: Masahiko Sawada and Amit Kapila Reviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra, Mahendra Singh and Sergei Kornilov Tested-by: Mahendra Singh and Prabhat Sahu Discussion: https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com
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;
^
Fix the usage of parallel and full options of vacuum command. Earlier we were inconsistent in allowing the usage of parallel and full options. Change it such that we disallow them only when they are combined in a way that we don't support. In passing, improve the comments in some of the existing tests of parallel vacuum. Reported-by: Tushar Ahuja Author: Justin Pryzby, Amit Kapila Reviewed-by: Sawada Masahiko, Michael Paquier, Mahendra Singh Thalor and Amit Kapila Discussion: https://postgr.es/m/58c8d171-e665-6fa3-a9d3-d9423b694dae%40enterprisedb.com
2020-04-16 07:14:03 +02:00
-- Test different combinations of parallel and full options for temporary tables
Allow vacuum command to process indexes in parallel. This feature allows the vacuum to leverage multiple CPUs in order to process indexes. This enables us to perform index vacuuming and index cleanup with background workers. This adds a PARALLEL option to VACUUM command where the user can specify the number of workers that can be used to perform the command which is limited by the number of indexes on a table. Specifying zero as a number of workers will disable parallelism. This option can't be used with the FULL option. Each index is processed by at most one vacuum process. Therefore parallel vacuum can be used when the table has at least two indexes. The parallel degree is either specified by the user or determined based on the number of indexes that the table has, and further limited by max_parallel_maintenance_workers. The index can participate in parallel vacuum iff it's size is greater than min_parallel_index_scan_size. Author: Masahiko Sawada and Amit Kapila Reviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra, Mahendra Singh and Sergei Kornilov Tested-by: Mahendra Singh and Prabhat Sahu Discussion: https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com
2020-01-20 03:27:49 +01:00
CREATE TEMPORARY TABLE tmp (a int PRIMARY KEY);
CREATE INDEX tmp_idx1 ON tmp (a);
Fix the usage of parallel and full options of vacuum command. Earlier we were inconsistent in allowing the usage of parallel and full options. Change it such that we disallow them only when they are combined in a way that we don't support. In passing, improve the comments in some of the existing tests of parallel vacuum. Reported-by: Tushar Ahuja Author: Justin Pryzby, Amit Kapila Reviewed-by: Sawada Masahiko, Michael Paquier, Mahendra Singh Thalor and Amit Kapila Discussion: https://postgr.es/m/58c8d171-e665-6fa3-a9d3-d9423b694dae%40enterprisedb.com
2020-04-16 07:14:03 +02:00
VACUUM (PARALLEL 1, FULL FALSE) tmp; -- parallel vacuum disabled for temp tables
Allow vacuum command to process indexes in parallel. This feature allows the vacuum to leverage multiple CPUs in order to process indexes. This enables us to perform index vacuuming and index cleanup with background workers. This adds a PARALLEL option to VACUUM command where the user can specify the number of workers that can be used to perform the command which is limited by the number of indexes on a table. Specifying zero as a number of workers will disable parallelism. This option can't be used with the FULL option. Each index is processed by at most one vacuum process. Therefore parallel vacuum can be used when the table has at least two indexes. The parallel degree is either specified by the user or determined based on the number of indexes that the table has, and further limited by max_parallel_maintenance_workers. The index can participate in parallel vacuum iff it's size is greater than min_parallel_index_scan_size. Author: Masahiko Sawada and Amit Kapila Reviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra, Mahendra Singh and Sergei Kornilov Tested-by: Mahendra Singh and Prabhat Sahu Discussion: https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com
2020-01-20 03:27:49 +01:00
WARNING: disabling parallel option of vacuum on "tmp" --- cannot vacuum temporary tables in parallel
Fix the usage of parallel and full options of vacuum command. Earlier we were inconsistent in allowing the usage of parallel and full options. Change it such that we disallow them only when they are combined in a way that we don't support. In passing, improve the comments in some of the existing tests of parallel vacuum. Reported-by: Tushar Ahuja Author: Justin Pryzby, Amit Kapila Reviewed-by: Sawada Masahiko, Michael Paquier, Mahendra Singh Thalor and Amit Kapila Discussion: https://postgr.es/m/58c8d171-e665-6fa3-a9d3-d9423b694dae%40enterprisedb.com
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)
Allow vacuum command to process indexes in parallel. This feature allows the vacuum to leverage multiple CPUs in order to process indexes. This enables us to perform index vacuuming and index cleanup with background workers. This adds a PARALLEL option to VACUUM command where the user can specify the number of workers that can be used to perform the command which is limited by the number of indexes on a table. Specifying zero as a number of workers will disable parallelism. This option can't be used with the FULL option. Each index is processed by at most one vacuum process. Therefore parallel vacuum can be used when the table has at least two indexes. The parallel degree is either specified by the user or determined based on the number of indexes that the table has, and further limited by max_parallel_maintenance_workers. The index can participate in parallel vacuum iff it's size is greater than min_parallel_index_scan_size. Author: Masahiko Sawada and Amit Kapila Reviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra, Mahendra Singh and Sergei Kornilov Tested-by: Mahendra Singh and Prabhat Sahu Discussion: https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com
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
Add toast-level reloption for vacuum_index_cleanup a96c41f has introduced the option for heap, but it still lacked the variant to control the behavior for toast relations. While on it, refactor the tests so as they stress more scenarios with the various values that vacuum_index_cleanup can use. It would be useful to couple those tests with pageinspect to check that pages are actually cleaned up, but this is left for later. Author: Masahiko Sawada, Michael Paquier Reviewed-by: Peter Geoghegan Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com
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),
Propagate ALTER TABLE ... SET STORAGE to indexes When creating a new index, the attstorage setting of the table column is copied to regular (non-expression) index columns. But a later ALTER TABLE ... SET STORAGE is not propagated to indexes, thus creating an inconsistent and undumpable state. Discussion: https://www.postgresql.org/message-id/flat/9765d72b-37c0-06f5-e349-2a580aafd989%402ndquadrant.com
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;
Add toast-level reloption for vacuum_index_cleanup a96c41f has introduced the option for heap, but it still lacked the variant to control the behavior for toast relations. While on it, refactor the tests so as they stress more scenarios with the various values that vacuum_index_cleanup can use. It would be useful to couple those tests with pageinspect to check that pages are actually cleaned up, but this is left for later. Author: Masahiko Sawada, Michael Paquier Reviewed-by: Peter Geoghegan Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com
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;
Support disabling index bypassing by VACUUM. Generalize the INDEX_CLEANUP VACUUM parameter (and the corresponding reloption): make it into a ternary style boolean parameter. It now exposes a third option, "auto". The "auto" option (which is now the default) enables the "bypass index vacuuming" optimization added by commit 1e55e7d1. "VACUUM (INDEX_CLEANUP TRUE)" is redefined to once again make VACUUM simply do any required index vacuuming, regardless of how few dead tuples are encountered during the first scan of the target heap relation (unless there are exactly zero). This gives users a way of opting out of the "bypass index vacuuming" optimization, if for whatever reason that proves necessary. It is also expected to be used by PostgreSQL developers as a testing option from time to time. "VACUUM (INDEX_CLEANUP FALSE)" does the same thing as it always has: it forcibly disables both index vacuuming and index cleanup. It's not expected to be used much in PostgreSQL 14. The failsafe mechanism added by commit 1e55e7d1 addresses the same problem in a simpler way. INDEX_CLEANUP can now be thought of as a testing and compatibility option. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/CAH2-WznrBoCST4_Gxh_G9hA8NzGUbeBGnOUC8FcXcrhqsv6OHQ@mail.gmail.com
2021-06-19 05:04:07 +02:00
ALTER TABLE no_index_cleanup SET (vacuum_index_cleanup = auto);
VACUUM no_index_cleanup;
Add toast-level reloption for vacuum_index_cleanup a96c41f has introduced the option for heap, but it still lacked the variant to control the behavior for toast relations. While on it, refactor the tests so as they stress more scenarios with the various values that vacuum_index_cleanup can use. It would be useful to couple those tests with pageinspect to check that pages are actually cleaned up, but this is left for later. Author: Masahiko Sawada, Michael Paquier Reviewed-by: Peter Geoghegan Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com
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),
Propagate ALTER TABLE ... SET STORAGE to indexes When creating a new index, the attstorage setting of the table column is copied to regular (non-expression) index columns. But a later ALTER TABLE ... SET STORAGE is not propagated to indexes, thus creating an inconsistent and undumpable state. Discussion: https://www.postgresql.org/message-id/flat/9765d72b-37c0-06f5-e349-2a580aafd989%402ndquadrant.com
2020-04-09 14:10:01 +02:00
repeat('1234567890',269));
Add toast-level reloption for vacuum_index_cleanup a96c41f has introduced the option for heap, but it still lacked the variant to control the behavior for toast relations. While on it, refactor the tests so as they stress more scenarios with the various values that vacuum_index_cleanup can use. It would be useful to couple those tests with pageinspect to check that pages are actually cleaned up, but this is left for later. Author: Masahiko Sawada, Michael Paquier Reviewed-by: Peter Geoghegan Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com
2019-06-25 02:09:27 +02:00
DELETE FROM no_index_cleanup WHERE i < 45;
-- Only toast index is cleaned up.
Support disabling index bypassing by VACUUM. Generalize the INDEX_CLEANUP VACUUM parameter (and the corresponding reloption): make it into a ternary style boolean parameter. It now exposes a third option, "auto". The "auto" option (which is now the default) enables the "bypass index vacuuming" optimization added by commit 1e55e7d1. "VACUUM (INDEX_CLEANUP TRUE)" is redefined to once again make VACUUM simply do any required index vacuuming, regardless of how few dead tuples are encountered during the first scan of the target heap relation (unless there are exactly zero). This gives users a way of opting out of the "bypass index vacuuming" optimization, if for whatever reason that proves necessary. It is also expected to be used by PostgreSQL developers as a testing option from time to time. "VACUUM (INDEX_CLEANUP FALSE)" does the same thing as it always has: it forcibly disables both index vacuuming and index cleanup. It's not expected to be used much in PostgreSQL 14. The failsafe mechanism added by commit 1e55e7d1 addresses the same problem in a simpler way. INDEX_CLEANUP can now be thought of as a testing and compatibility option. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/CAH2-WznrBoCST4_Gxh_G9hA8NzGUbeBGnOUC8FcXcrhqsv6OHQ@mail.gmail.com
2021-06-19 05:04:07 +02:00
ALTER TABLE no_index_cleanup SET (vacuum_index_cleanup = off,
toast.vacuum_index_cleanup = yes);
Add toast-level reloption for vacuum_index_cleanup a96c41f has introduced the option for heap, but it still lacked the variant to control the behavior for toast relations. While on it, refactor the tests so as they stress more scenarios with the various values that vacuum_index_cleanup can use. It would be useful to couple those tests with pageinspect to check that pages are actually cleaned up, but this is left for later. Author: Masahiko Sawada, Michael Paquier Reviewed-by: Peter Geoghegan Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com
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;
Support disabling index bypassing by VACUUM. Generalize the INDEX_CLEANUP VACUUM parameter (and the corresponding reloption): make it into a ternary style boolean parameter. It now exposes a third option, "auto". The "auto" option (which is now the default) enables the "bypass index vacuuming" optimization added by commit 1e55e7d1. "VACUUM (INDEX_CLEANUP TRUE)" is redefined to once again make VACUUM simply do any required index vacuuming, regardless of how few dead tuples are encountered during the first scan of the target heap relation (unless there are exactly zero). This gives users a way of opting out of the "bypass index vacuuming" optimization, if for whatever reason that proves necessary. It is also expected to be used by PostgreSQL developers as a testing option from time to time. "VACUUM (INDEX_CLEANUP FALSE)" does the same thing as it always has: it forcibly disables both index vacuuming and index cleanup. It's not expected to be used much in PostgreSQL 14. The failsafe mechanism added by commit 1e55e7d1 addresses the same problem in a simpler way. INDEX_CLEANUP can now be thought of as a testing and compatibility option. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/CAH2-WznrBoCST4_Gxh_G9hA8NzGUbeBGnOUC8FcXcrhqsv6OHQ@mail.gmail.com
2021-06-19 05:04:07 +02:00
VACUUM (INDEX_CLEANUP AUTO) vactst; -- index cleanup option is ignored if no indexes
Add toast-level reloption for vacuum_index_cleanup a96c41f has introduced the option for heap, but it still lacked the variant to control the behavior for toast relations. While on it, refactor the tests so as they stress more scenarios with the various values that vacuum_index_cleanup can use. It would be useful to couple those tests with pageinspect to check that pages are actually cleaned up, but this is left for later. Author: Masahiko Sawada, Michael Paquier Reviewed-by: Peter Geoghegan Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com
2019-06-25 02:09:27 +02:00
VACUUM (INDEX_CLEANUP FALSE, FREEZE TRUE) vaccluster;
Add TRUNCATE parameter to VACUUM. This commit adds new parameter to VACUUM command, TRUNCATE, which specifies that VACUUM should attempt to truncate off any empty pages at the end of the table and allow the disk space for the truncated pages to be returned to the operating system. This parameter, if specified, overrides the vacuum_truncate reloption. If neither the reloption nor the VACUUM option is used, the default is true, as before. Author: Fujii Masao Reviewed-by: Julien Rouhaud, Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoD+qtrSDL=GSma4Wd3kLYLeRC0hPna-YAdkDeV4z156vg@mail.gmail.com
2019-05-07 19:10:33 +02:00
-- TRUNCATE option
Try to stabilize vacuum test. As commits b700f96c and 3414099c did for the reloptions test, make sure VACUUM can always truncate the table as expected. Back-patch to 12, where vacuum_truncate arrived. Discussion: https://postgr.es/m/CAD21AoCNoWjYkdEtr%2BVDoF9v__V905AedKZ9iF%3DArgCtrbxZqw%40mail.gmail.com
2022-03-23 02:31:18 +01:00
CREATE TEMP TABLE vac_truncate_test(i INT NOT NULL, j text)
Add TRUNCATE parameter to VACUUM. This commit adds new parameter to VACUUM command, TRUNCATE, which specifies that VACUUM should attempt to truncate off any empty pages at the end of the table and allow the disk space for the truncated pages to be returned to the operating system. This parameter, if specified, overrides the vacuum_truncate reloption. If neither the reloption nor the VACUUM option is used, the default is true, as before. Author: Fujii Masao Reviewed-by: Julien Rouhaud, Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoD+qtrSDL=GSma4Wd3kLYLeRC0hPna-YAdkDeV4z156vg@mail.gmail.com
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);
Added relation name in error messages for constraint checks. This gives more information to the user about the error and it makes such messages consistent with the other similar messages in the code. Reported-by: Simon Riggs Author: Mahendra Singh and Simon Riggs Reviewed-by: Beena Emerson and Amit Kapila Discussion: https://postgr.es/m/CANP8+j+7YUvQvGxTrCiw77R23enMJ7DFmyA3buR+fa2pKs4XhA@mail.gmail.com
2020-01-28 03:18:10 +01:00
ERROR: null value in column "i" of relation "vac_truncate_test" violates not-null constraint
Add TRUNCATE parameter to VACUUM. This commit adds new parameter to VACUUM command, TRUNCATE, which specifies that VACUUM should attempt to truncate off any empty pages at the end of the table and allow the disk space for the truncated pages to be returned to the operating system. This parameter, if specified, overrides the vacuum_truncate reloption. If neither the reloption nor the VACUUM option is used, the default is true, as before. Author: Fujii Masao Reviewed-by: Julien Rouhaud, Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoD+qtrSDL=GSma4Wd3kLYLeRC0hPna-YAdkDeV4z156vg@mail.gmail.com
2019-05-07 19:10:33 +02:00
DETAIL: Failing row contains (null, null).
Try to stabilize vacuum test. As commits b700f96c and 3414099c did for the reloptions test, make sure VACUUM can always truncate the table as expected. Back-patch to 12, where vacuum_truncate arrived. Discussion: https://postgr.es/m/CAD21AoCNoWjYkdEtr%2BVDoF9v__V905AedKZ9iF%3DArgCtrbxZqw%40mail.gmail.com
2022-03-23 02:31:18 +01:00
VACUUM (TRUNCATE FALSE, DISABLE_PAGE_SKIPPING) vac_truncate_test;
Add TRUNCATE parameter to VACUUM. This commit adds new parameter to VACUUM command, TRUNCATE, which specifies that VACUUM should attempt to truncate off any empty pages at the end of the table and allow the disk space for the truncated pages to be returned to the operating system. This parameter, if specified, overrides the vacuum_truncate reloption. If neither the reloption nor the VACUUM option is used, the default is true, as before. Author: Fujii Masao Reviewed-by: Julien Rouhaud, Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoD+qtrSDL=GSma4Wd3kLYLeRC0hPna-YAdkDeV4z156vg@mail.gmail.com
2019-05-07 19:10:33 +02:00
SELECT pg_relation_size('vac_truncate_test') > 0;
?column?
----------
t
(1 row)
Try to stabilize vacuum test. As commits b700f96c and 3414099c did for the reloptions test, make sure VACUUM can always truncate the table as expected. Back-patch to 12, where vacuum_truncate arrived. Discussion: https://postgr.es/m/CAD21AoCNoWjYkdEtr%2BVDoF9v__V905AedKZ9iF%3DArgCtrbxZqw%40mail.gmail.com
2022-03-23 02:31:18 +01:00
VACUUM (DISABLE_PAGE_SKIPPING) vac_truncate_test;
Add TRUNCATE parameter to VACUUM. This commit adds new parameter to VACUUM command, TRUNCATE, which specifies that VACUUM should attempt to truncate off any empty pages at the end of the table and allow the disk space for the truncated pages to be returned to the operating system. This parameter, if specified, overrides the vacuum_truncate reloption. If neither the reloption nor the VACUUM option is used, the default is true, as before. Author: Fujii Masao Reviewed-by: Julien Rouhaud, Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoD+qtrSDL=GSma4Wd3kLYLeRC0hPna-YAdkDeV4z156vg@mail.gmail.com
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;
Fix relcache reference leak. Reported by Kevin Grittner. Faulty commit identified by Tom Lane. Patch by Amit Langote, reviewed by Michael Paquier. Discussion: http://postgr.es/m/CACjxUsOHbH1=99u8mGxmLHfy5hov4ENEpvM6=3ARjos7wG7rtQ@mail.gmail.com
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;
Give a better error for duplicate entries in VACUUM/ANALYZE column list. Previously, the code didn't think about this case and would just try to analyze such a column twice. That would fail at the point of inserting the second version of the pg_statistic row, with obscure error messsages like "duplicate key value violates unique constraint" or "tuple already updated by self", depending on context and PG version. We could allow the case by ignoring duplicate column specifications, but it seems better to reject it explicitly. The bogus error messages seem like arguably a bug, so back-patch to all supported versions. Nathan Bossart, per a report from Michael Paquier, and whacked around a bit by me. Discussion: https://postgr.es/m/E061A8E3-5E3D-494D-94F0-E8A9B312BBFC@amazon.com
2017-09-22 00:13:11 +02:00
-- check behavior with duplicate column mentions
VACUUM ANALYZE vacparted(a,b,a);
Improve wording of error message added in commit 714805010. Per suggestions from Peter Eisentraut and David Johnston. Back-patch, like the previous commit. Discussion: https://postgr.es/m/E1dv9jI-0006oT-Fn@gemulon.postgresql.org
2017-09-26 21:25:56 +02:00
ERROR: column "a" of relation "vacparted" appears more than once
Give a better error for duplicate entries in VACUUM/ANALYZE column list. Previously, the code didn't think about this case and would just try to analyze such a column twice. That would fail at the point of inserting the second version of the pg_statistic row, with obscure error messsages like "duplicate key value violates unique constraint" or "tuple already updated by self", depending on context and PG version. We could allow the case by ignoring duplicate column specifications, but it seems better to reject it explicitly. The bogus error messages seem like arguably a bug, so back-patch to all supported versions. Nathan Bossart, per a report from Michael Paquier, and whacked around a bit by me. Discussion: https://postgr.es/m/E061A8E3-5E3D-494D-94F0-E8A9B312BBFC@amazon.com
2017-09-22 00:13:11 +02:00
ANALYZE vacparted(a,b,b);
Improve wording of error message added in commit 714805010. Per suggestions from Peter Eisentraut and David Johnston. Back-patch, like the previous commit. Discussion: https://postgr.es/m/E1dv9jI-0006oT-Fn@gemulon.postgresql.org
2017-09-26 21:25:56 +02:00
ERROR: column "b" of relation "vacparted" appears more than once
Don't reset relhasindex for partitioned tables on ANALYZE Commit 0e69f705cc1a introduced code to analyze partitioned table; however, that code fails to preserve pg_class.relhasindex correctly. Fix by observing whether any indexes exist rather than accidentally falling through to assuming none do. Backpatch to 14. Author: Alexander Pyhalov <a.pyhalov@postgrespro.ru> Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Discussion: https://postgr.es/m/CALNJ-vS1R3Qoe5t4tbzxrkpBtzRbPq1dDcW4RmA_a+oqweF30w@mail.gmail.com
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;
Allow multiple tables to be specified in one VACUUM or ANALYZE command. Not much to say about this; does what it says on the tin. However, formerly, if there was a column list then the ANALYZE action was implied; now it must be specified, or you get an error. This is because it would otherwise be a bit unclear what the user meant if some tables have column lists and some don't. Nathan Bossart, reviewed by Michael Paquier and Masahiko Sawada, with some editorialization by me Discussion: https://postgr.es/m/E061A8E3-5E3D-494D-94F0-E8A9B312BBFC@amazon.com
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;
Add parenthesized options syntax for ANALYZE. This is analogous to the syntax allowed for VACUUM. This allows us to avoid making new options reserved keywords and makes it easier to allow arbitrary argument order. Oh, and it's consistent with the other commands, too. Author: Nathan Bossart Reviewed-By: Michael Paquier, Masahiko Sawada Discussion: https://postgr.es/m/D3FC73E2-9B1A-4DB4-8180-55F57D116B4E@amazon.com
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
Add option SKIP_LOCKED to VACUUM and ANALYZE When specified, this option allows VACUUM to skip the work on a relation if there is a conflicting lock on it when trying to open it at the beginning of its processing. Similarly to autovacuum, this comes with a couple of limitations while the relation is processed which can cause the process to still block: - when opening the relation indexes. - when acquiring row samples for table inheritance trees, partition trees or certain types of foreign tables, and that a lock is taken on some leaves of such trees. Author: Nathan Bossart Reviewed-by: Michael Paquier, Andres Freund, Masahiko Sawada Discussion: https://postgr.es/m/9EF7EBE4-720D-4CF1-9D0E-4403D7E92990@amazon.com Discussion: https://postgr.es/m/20171201160907.27110.74730@wrigleys.postgresql.org
2018-10-04 02:00:33 +02:00
ANALYZE (nonexistent-arg) does_not_exist;
Fix regression tests broken in fc7c281f87467. This shouldn't have been committed without even running the tests (nor were the tests added that were suggested). I'm fixing up the results to get the buildfarm back to green, it's quite possible we'll want to revert this later.
2019-05-20 18:36:06 +02:00
ERROR: syntax error at or near "arg"
Add option SKIP_LOCKED to VACUUM and ANALYZE When specified, this option allows VACUUM to skip the work on a relation if there is a conflicting lock on it when trying to open it at the beginning of its processing. Similarly to autovacuum, this comes with a couple of limitations while the relation is processed which can cause the process to still block: - when opening the relation indexes. - when acquiring row samples for table inheritance trees, partition trees or certain types of foreign tables, and that a lock is taken on some leaves of such trees. Author: Nathan Bossart Reviewed-by: Michael Paquier, Andres Freund, Masahiko Sawada Discussion: https://postgr.es/m/9EF7EBE4-720D-4CF1-9D0E-4403D7E92990@amazon.com Discussion: https://postgr.es/m/20171201160907.27110.74730@wrigleys.postgresql.org
2018-10-04 02:00:33 +02:00
LINE 1: ANALYZE (nonexistent-arg) does_not_exist;
Fix regression tests broken in fc7c281f87467. This shouldn't have been committed without even running the tests (nor were the tests added that were suggested). I'm fixing up the results to get the buildfarm back to green, it's quite possible we'll want to revert this later.
2019-05-20 18:36:06 +02:00
^
Revise parse tree representation for VACUUM and ANALYZE. Like commit f41551f61f9cf4eedd5b7173f985a3bdb4d9858c, this aims to make it easier to add non-Boolean options to VACUUM (or, in this case, to ANALYZE). Instead of building up a bitmap of options directly in the parser, build up a list of DefElem objects and let ExecVacuum() sort it out; right now, we make no use of the fact that a DefElem can carry an associated value, but it will be easy to make that change in the future. Masahiko Sawada Discussion: http://postgr.es/m/CAD21AoATE4sn0jFFH3NcfUZXkU2BMbjBWB_kDj-XWYA-LXDcQA@mail.gmail.com
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;
Add parenthesized options syntax for ANALYZE. This is analogous to the syntax allowed for VACUUM. This allows us to avoid making new options reserved keywords and makes it easier to allow arbitrary argument order. Oh, and it's consistent with the other commands, too. Author: Nathan Bossart Reviewed-By: Michael Paquier, Masahiko Sawada Discussion: https://postgr.es/m/D3FC73E2-9B1A-4DB4-8180-55F57D116B4E@amazon.com
2018-03-06 01:21:05 +01:00
^
Add option SKIP_LOCKED to VACUUM and ANALYZE When specified, this option allows VACUUM to skip the work on a relation if there is a conflicting lock on it when trying to open it at the beginning of its processing. Similarly to autovacuum, this comes with a couple of limitations while the relation is processed which can cause the process to still block: - when opening the relation indexes. - when acquiring row samples for table inheritance trees, partition trees or certain types of foreign tables, and that a lock is taken on some leaves of such trees. Author: Nathan Bossart Reviewed-by: Michael Paquier, Andres Freund, Masahiko Sawada Discussion: https://postgr.es/m/9EF7EBE4-720D-4CF1-9D0E-4403D7E92990@amazon.com Discussion: https://postgr.es/m/20171201160907.27110.74730@wrigleys.postgresql.org
2018-10-04 02:00:33 +02:00
-- ensure argument order independence, and that SKIP_LOCKED on non-existing
Improve stability of tests for VACUUM (SKIP_LOCKED) Concurrent autovacuums running with the main regression test suite could cause the tests with VACUUM (SKIP_LOCKED) to generate randomly WARNING messages. For these tests, set client_min_messages to ERROR to get rid of those random failures, as disabling autovacuum for the relations operated would not completely close the failure window. For isolation tests, disable autovacuum for the relations vacuumed with SKIP_LOCKED. The tests are designed so as LOCK commands are taken in a first session before running a concurrent VACUUM (SKIP_LOCKED) in a second to generate WARNING messages, but a concurrent autovacuum could cause the tests to be slower. Reported-by: Tom Lane Author: Michael Paquier Reviewed-by: Andres Freund, Tom Lane Discussion: https://postgr.es/m/25294.1573077278@sss.pgh.pa.us Backpatch-through: 12
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';
Add option SKIP_LOCKED to VACUUM and ANALYZE When specified, this option allows VACUUM to skip the work on a relation if there is a conflicting lock on it when trying to open it at the beginning of its processing. Similarly to autovacuum, this comes with a couple of limitations while the relation is processed which can cause the process to still block: - when opening the relation indexes. - when acquiring row samples for table inheritance trees, partition trees or certain types of foreign tables, and that a lock is taken on some leaves of such trees. Author: Nathan Bossart Reviewed-by: Michael Paquier, Andres Freund, Masahiko Sawada Discussion: https://postgr.es/m/9EF7EBE4-720D-4CF1-9D0E-4403D7E92990@amazon.com Discussion: https://postgr.es/m/20171201160907.27110.74730@wrigleys.postgresql.org
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;
Improve stability of tests for VACUUM (SKIP_LOCKED) Concurrent autovacuums running with the main regression test suite could cause the tests with VACUUM (SKIP_LOCKED) to generate randomly WARNING messages. For these tests, set client_min_messages to ERROR to get rid of those random failures, as disabling autovacuum for the relations operated would not completely close the failure window. For isolation tests, disable autovacuum for the relations vacuumed with SKIP_LOCKED. The tests are designed so as LOCK commands are taken in a first session before running a concurrent VACUUM (SKIP_LOCKED) in a second to generate WARNING messages, but a concurrent autovacuum could cause the tests to be slower. Reported-by: Tom Lane Author: Michael Paquier Reviewed-by: Andres Freund, Tom Lane Discussion: https://postgr.es/m/25294.1573077278@sss.pgh.pa.us Backpatch-through: 12
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;
Add option PROCESS_TOAST to VACUUM This option controls if toast tables associated with a relation are vacuumed or not when running a manual VACUUM. It was already possible to trigger a manual VACUUM on a toast relation without processing its main relation, but a manual vacuum on a main relation always forced a vacuum on its toast table. This is useful in scenarios where the level of bloat or transaction age of the main and toast relations differs a lot. This option is an extension of the existing VACOPT_SKIPTOAST that was used by autovacuum to control if toast relations should be skipped or not. This internal flag is renamed to VACOPT_PROCESS_TOAST for consistency with the new option. A new option switch, called --no-process-toast, is added to vacuumdb. Author: Nathan Bossart Reviewed-by: Kirk Jamison, Michael Paquier, Justin Pryzby Discussion: https://postgr.es/m/BA8951E9-1524-48C5-94AF-73B1F0D7857F@amazon.com
2021-02-09 06:13:57 +01:00
-- PROCESS_TOAST option
Improve the regression tests of VACUUM (PROCESS_TOAST) All the regression tests of VACUUM (PROCESS_TOAST) were only checking if the commands were able to run, without checking if VACUUM was really running on what it should. This expands this set of tests so as we now look at pg_stat_all_tables.vacuum_count to see how many vacuums have been run on a given table and its toast relation. Extracted from a larger patch by the same author, as this is useful on its own. Special thanks to Álvaro Herrera for the idea of using pg_stat_all_tables to check the state of the toast relation. Author: Nathan Bossart Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/20221230000028.GA435655@nathanxps13
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
Add PROCESS_MAIN to VACUUM Disabling this option is useful to run VACUUM (with or without FULL) on only the toast table of a relation, bypassing the main relation. This option is enabled by default. Running directly VACUUM on a toast table was already possible without this feature, by using the non-deterministic name of a toast relation (as of pg_toast.pg_toast_N, where N would be the OID of the parent relation) in the VACUUM command, and it required a scan of pg_class to know the name of the toast table. So this feature is basically a shortcut to be able to run VACUUM or VACUUM FULL on a toast relation, using only the name of the parent relation. A new switch called --no-process-main is added to vacuumdb, to work as an equivalent of PROCESS_MAIN. Regression tests are added to cover VACUUM and VACUUM FULL, looking at pg_stat_all_tables.vacuum_count to see how many vacuums have run on each table, main or toast. Author: Nathan Bossart Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/20221230000028.GA435655@nathanxps13
2023-03-06 08:41:05 +01:00
-- toast relation, to check that PROCESS_TOAST and PROCESS_MAIN work on
-- what they should.
Improve the regression tests of VACUUM (PROCESS_TOAST) All the regression tests of VACUUM (PROCESS_TOAST) were only checking if the commands were able to run, without checking if VACUUM was really running on what it should. This expands this set of tests so as we now look at pg_stat_all_tables.vacuum_count to see how many vacuums have been run on a given table and its toast relation. Extracted from a larger patch by the same author, as this is useful on its own. Special thanks to Álvaro Herrera for the idea of using pg_stat_all_tables to check the state of the toast relation. Author: Nathan Bossart Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/20221230000028.GA435655@nathanxps13
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
Add option PROCESS_TOAST to VACUUM This option controls if toast tables associated with a relation are vacuumed or not when running a manual VACUUM. It was already possible to trigger a manual VACUUM on a toast relation without processing its main relation, but a manual vacuum on a main relation always forced a vacuum on its toast table. This is useful in scenarios where the level of bloat or transaction age of the main and toast relations differs a lot. This option is an extension of the existing VACOPT_SKIPTOAST that was used by autovacuum to control if toast relations should be skipped or not. This internal flag is renamed to VACOPT_PROCESS_TOAST for consistency with the new option. A new option switch, called --no-process-toast, is added to vacuumdb. Author: Nathan Bossart Reviewed-by: Kirk Jamison, Michael Paquier, Justin Pryzby Discussion: https://postgr.es/m/BA8951E9-1524-48C5-94AF-73B1F0D7857F@amazon.com
2021-02-09 06:13:57 +01:00
ERROR: PROCESS_TOAST required with VACUUM FULL
Add PROCESS_MAIN to VACUUM Disabling this option is useful to run VACUUM (with or without FULL) on only the toast table of a relation, bypassing the main relation. This option is enabled by default. Running directly VACUUM on a toast table was already possible without this feature, by using the non-deterministic name of a toast relation (as of pg_toast.pg_toast_N, where N would be the OID of the parent relation) in the VACUUM command, and it required a scan of pg_class to know the name of the toast table. So this feature is basically a shortcut to be able to run VACUUM or VACUUM FULL on a toast relation, using only the name of the parent relation. A new switch called --no-process-main is added to vacuumdb, to work as an equivalent of PROCESS_MAIN. Regression tests are added to cover VACUUM and VACUUM FULL, looking at pg_stat_all_tables.vacuum_count to see how many vacuums have run on each table, main or toast. Author: Nathan Bossart Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/20221230000028.GA435655@nathanxps13
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)
Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option Add new options to the VACUUM and ANALYZE commands called BUFFER_USAGE_LIMIT to allow users more control over how large to make the buffer access strategy that is used to limit the usage of buffers in shared buffers. Larger rings can allow VACUUM to run more quickly but have the drawback of VACUUM possibly evicting more buffers from shared buffers that might be useful for other queries running on the database. Here we also add a new GUC named vacuum_buffer_usage_limit which controls how large to make the access strategy when it's not specified in the VACUUM/ANALYZE command. This defaults to 256KB, which is the same size as the access strategy was prior to this change. This setting also controls how large to make the buffer access strategy for autovacuum. Per idea by Andres Freund. Author: Melanie Plageman Reviewed-by: David Rowley Reviewed-by: Andres Freund Reviewed-by: Justin Pryzby Reviewed-by: Bharath Rupireddy Discussion: https://postgr.es/m/20230111182720.ejifsclfwymw2reb@awork3.anarazel.de
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;
Improve ereports for VACUUM's BUFFER_USAGE_LIMIT option There's no need to check if opt->arg is NULL since defGetString() already does that and raises an ERROR if it is. Let's just remove that check. Also, combine the two remaining ERRORs into a single check. It seems better to give an indication about what sort of values we're looking for rather than just to state that the value given isn't valid. Make BUFFER_USAGE_LIMIT uppercase in this ERROR message too. It's already upper case in one other error message, so make that consistent. Reported-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20230411.102335.1643720544536884844.horikyota.ntt@gmail.com
2023-04-11 09:36:34 +02:00
ERROR: BUFFER_USAGE_LIMIT option must be 0 or between 128 kB and 16777216 kB
Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option Add new options to the VACUUM and ANALYZE commands called BUFFER_USAGE_LIMIT to allow users more control over how large to make the buffer access strategy that is used to limit the usage of buffers in shared buffers. Larger rings can allow VACUUM to run more quickly but have the drawback of VACUUM possibly evicting more buffers from shared buffers that might be useful for other queries running on the database. Here we also add a new GUC named vacuum_buffer_usage_limit which controls how large to make the access strategy when it's not specified in the VACUUM/ANALYZE command. This defaults to 256KB, which is the same size as the access strategy was prior to this change. This setting also controls how large to make the buffer access strategy for autovacuum. Per idea by Andres Freund. Author: Melanie Plageman Reviewed-by: David Rowley Reviewed-by: Andres Freund Reviewed-by: Justin Pryzby Reviewed-by: Bharath Rupireddy Discussion: https://postgr.es/m/20230111182720.ejifsclfwymw2reb@awork3.anarazel.de
2023-04-07 01:40:31 +02:00
-- value is less than min size error
VACUUM (BUFFER_USAGE_LIMIT 120) vac_option_tab;
Improve ereports for VACUUM's BUFFER_USAGE_LIMIT option There's no need to check if opt->arg is NULL since defGetString() already does that and raises an ERROR if it is. Let's just remove that check. Also, combine the two remaining ERRORs into a single check. It seems better to give an indication about what sort of values we're looking for rather than just to state that the value given isn't valid. Make BUFFER_USAGE_LIMIT uppercase in this ERROR message too. It's already upper case in one other error message, so make that consistent. Reported-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20230411.102335.1643720544536884844.horikyota.ntt@gmail.com
2023-04-11 09:36:34 +02:00
ERROR: BUFFER_USAGE_LIMIT option must be 0 or between 128 kB and 16777216 kB
Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option Add new options to the VACUUM and ANALYZE commands called BUFFER_USAGE_LIMIT to allow users more control over how large to make the buffer access strategy that is used to limit the usage of buffers in shared buffers. Larger rings can allow VACUUM to run more quickly but have the drawback of VACUUM possibly evicting more buffers from shared buffers that might be useful for other queries running on the database. Here we also add a new GUC named vacuum_buffer_usage_limit which controls how large to make the access strategy when it's not specified in the VACUUM/ANALYZE command. This defaults to 256KB, which is the same size as the access strategy was prior to this change. This setting also controls how large to make the buffer access strategy for autovacuum. Per idea by Andres Freund. Author: Melanie Plageman Reviewed-by: David Rowley Reviewed-by: Andres Freund Reviewed-by: Justin Pryzby Reviewed-by: Bharath Rupireddy Discussion: https://postgr.es/m/20230111182720.ejifsclfwymw2reb@awork3.anarazel.de
2023-04-07 01:40:31 +02:00
-- integer overflow error
VACUUM (BUFFER_USAGE_LIMIT 10000000000) vac_option_tab;
Improve ereports for VACUUM's BUFFER_USAGE_LIMIT option There's no need to check if opt->arg is NULL since defGetString() already does that and raises an ERROR if it is. Let's just remove that check. Also, combine the two remaining ERRORs into a single check. It seems better to give an indication about what sort of values we're looking for rather than just to state that the value given isn't valid. Make BUFFER_USAGE_LIMIT uppercase in this ERROR message too. It's already upper case in one other error message, so make that consistent. Reported-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20230411.102335.1643720544536884844.horikyota.ntt@gmail.com
2023-04-11 09:36:34 +02:00
ERROR: BUFFER_USAGE_LIMIT option must be 0 or between 128 kB and 16777216 kB
Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option Add new options to the VACUUM and ANALYZE commands called BUFFER_USAGE_LIMIT to allow users more control over how large to make the buffer access strategy that is used to limit the usage of buffers in shared buffers. Larger rings can allow VACUUM to run more quickly but have the drawback of VACUUM possibly evicting more buffers from shared buffers that might be useful for other queries running on the database. Here we also add a new GUC named vacuum_buffer_usage_limit which controls how large to make the access strategy when it's not specified in the VACUUM/ANALYZE command. This defaults to 256KB, which is the same size as the access strategy was prior to this change. This setting also controls how large to make the buffer access strategy for autovacuum. Per idea by Andres Freund. Author: Melanie Plageman Reviewed-by: David Rowley Reviewed-by: Andres Freund Reviewed-by: Justin Pryzby Reviewed-by: Bharath Rupireddy Discussion: https://postgr.es/m/20230111182720.ejifsclfwymw2reb@awork3.anarazel.de
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
Add options to control whether VACUUM runs vac_update_datfrozenxid. VACUUM normally ends by running vac_update_datfrozenxid(), which requires a scan of pg_class. Therefore, if one attempts to vacuum a database one table at a time --- as vacuumdb has done since v12 --- we will spend O(N^2) time in vac_update_datfrozenxid(). That causes serious performance problems in databases with tens of thousands of tables, and indeed the effect is measurable with only a few hundred. To add insult to injury, only one process can run vac_update_datfrozenxid at the same time per DB, so this behavior largely defeats vacuumdb's -j option. Hence, invent options SKIP_DATABASE_STATS and ONLY_DATABASE_STATS to allow applications to postpone vac_update_datfrozenxid() until the end of a series of VACUUM requests, and teach vacuumdb to use them. Per bug #17717 from Gunnar L. Sadly, this answer doesn't seem like something we'd consider back-patching, so the performance problem will remain in v12-v15. Tom Lane and Nathan Bossart Discussion: https://postgr.es/m/17717-6c50eb1c7d23a886@postgresql.org
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
Improve the regression tests of VACUUM (PROCESS_TOAST) All the regression tests of VACUUM (PROCESS_TOAST) were only checking if the commands were able to run, without checking if VACUUM was really running on what it should. This expands this set of tests so as we now look at pg_stat_all_tables.vacuum_count to see how many vacuums have been run on a given table and its toast relation. Extracted from a larger patch by the same author, as this is useful on its own. Special thanks to Álvaro Herrera for the idea of using pg_stat_all_tables to check the state of the toast relation. Author: Nathan Bossart Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/20221230000028.GA435655@nathanxps13
2023-03-06 07:40:56 +01:00
DROP VIEW vac_option_tab_counts;
DROP TABLE vac_option_tab;
Allow multiple tables to be specified in one VACUUM or ANALYZE command. Not much to say about this; does what it says on the tin. However, formerly, if there was a column list then the ANALYZE action was implied; now it must be specified, or you get an error. This is because it would otherwise be a bit unclear what the user meant if some tables have column lists and some don't. Nathan Bossart, reviewed by Michael Paquier and Masahiko Sawada, with some editorialization by me Discussion: https://postgr.es/m/E061A8E3-5E3D-494D-94F0-E8A9B312BBFC@amazon.com
2017-10-04 00:53:44 +02:00
DROP TABLE vaccluster;
DROP TABLE vactst;
Fix relcache reference leak. Reported by Kevin Grittner. Faulty commit identified by Tom Lane. Patch by Amit Langote, reviewed by Michael Paquier. Discussion: http://postgr.es/m/CACjxUsOHbH1=99u8mGxmLHfy5hov4ENEpvM6=3ARjos7wG7rtQ@mail.gmail.com
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;
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
-- relation ownership, WARNING logs generated as all are skipped.
CREATE TABLE vacowned (a int);
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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);
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
CREATE ROLE regress_vacuum;
SET ROLE regress_vacuum;
-- Simple table
VACUUM vacowned;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "vacowned", skipping it
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
ANALYZE vacowned;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to analyze "vacowned", skipping it
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
VACUUM (ANALYZE) vacowned;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "vacowned", skipping it
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
-- Catalog
VACUUM pg_catalog.pg_class;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "pg_class", skipping it
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
ANALYZE pg_catalog.pg_class;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to analyze "pg_class", skipping it
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
VACUUM (ANALYZE) pg_catalog.pg_class;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "pg_class", skipping it
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
-- Shared catalog
VACUUM pg_catalog.pg_authid;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "pg_authid", skipping it
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
ANALYZE pg_catalog.pg_authid;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to analyze "pg_authid", skipping it
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
VACUUM (ANALYZE) pg_catalog.pg_authid;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "pg_authid", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
VACUUM vacowned_part1;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "vacowned_part1", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
VACUUM vacowned_part2;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "vacowned_part2", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
ANALYZE vacowned_parted;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
ANALYZE vacowned_part1;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to analyze "vacowned_part1", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
ANALYZE vacowned_part2;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to analyze "vacowned_part2", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
VACUUM (ANALYZE) vacowned_parted;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
VACUUM (ANALYZE) vacowned_part1;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "vacowned_part1", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
VACUUM (ANALYZE) vacowned_part2;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "vacowned_part2", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
VACUUM vacowned_part1;
VACUUM vacowned_part2;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "vacowned_part2", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
ANALYZE vacowned_parted;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
ANALYZE vacowned_part1;
ANALYZE vacowned_part2;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to analyze "vacowned_part2", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
VACUUM (ANALYZE) vacowned_parted;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
VACUUM (ANALYZE) vacowned_part1;
VACUUM (ANALYZE) vacowned_part2;
Simplify WARNING messages from skipped vacuum/analyze on a table This will more easily accomodate adding new permissions for vacuum and analyze. Nathan Bossart following a suggestion from Kyotaro Horiguchi Discussion: https://postgr.es/m/20220726.104712.912995710251150228.horikyota.ntt@gmail.com
2022-11-23 20:41:30 +01:00
WARNING: permission denied to vacuum "vacowned_part2", skipping it
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
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
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
RESET ROLE;
DROP TABLE vacowned;
Add more tests for VACUUM skips with partitioned tables A VACUUM or ANALYZE command listing directly a partitioned table expands it to its partitions, causing all elements of a tree to be processed with individual ownership checks done. This results in different relation skips depending on the ownership policy of a tree, which may not be consistent for a partition tree. This commit adds more tests to ensure that any future refactoring allows to keep a consistent behavior, or at least that any changes done are easily identified and checked. The current behavior of VACUUM with partitioned tables is present since 10. Author: Nathan Bossart Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/DC186201-B01F-4A66-9EC4-F855A957C1F9@amazon.com
2018-08-24 02:15:08 +02:00
DROP TABLE vacowned_parted;
Add regression tests for VACUUM and ANALYZE with relation skips When a user does not have ownership on a relation, then specific log messages are generated. This new test suite adds coverage for all the possible log messages generated, which will be useful to check the consistency of any refactoring related to ownership checks for relations vacuumed or analyzed. Author: Michael Paquier Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/20180812222142.GA6097@paquier.xyz
2018-08-22 02:41:37 +02:00
DROP ROLE regress_vacuum;