2022-04-26 06:41:17 +02:00
|
|
|
Parsed test spec with 2 sessions
|
|
|
|
|
|
|
|
starting permutation: s1_begin s1_lock_parent s2_auth s2_cluster s1_commit s2_reset
|
|
|
|
step s1_begin: BEGIN;
|
|
|
|
step s1_lock_parent: LOCK cluster_part_tab IN SHARE UPDATE EXCLUSIVE MODE;
|
2024-03-13 20:49:26 +01:00
|
|
|
step s2_auth: SET ROLE regress_cluster_part; SET client_min_messages = ERROR;
|
2022-04-26 06:41:17 +02:00
|
|
|
step s2_cluster: CLUSTER cluster_part_tab USING cluster_part_ind; <waiting ...>
|
|
|
|
step s1_commit: COMMIT;
|
|
|
|
step s2_cluster: <... completed>
|
|
|
|
step s2_reset: RESET ROLE;
|
|
|
|
|
|
|
|
starting permutation: s1_begin s2_auth s1_lock_parent s2_cluster s1_commit s2_reset
|
|
|
|
step s1_begin: BEGIN;
|
2024-03-13 20:49:26 +01:00
|
|
|
step s2_auth: SET ROLE regress_cluster_part; SET client_min_messages = ERROR;
|
2022-04-26 06:41:17 +02:00
|
|
|
step s1_lock_parent: LOCK cluster_part_tab IN SHARE UPDATE EXCLUSIVE MODE;
|
|
|
|
step s2_cluster: CLUSTER cluster_part_tab USING cluster_part_ind; <waiting ...>
|
|
|
|
step s1_commit: COMMIT;
|
|
|
|
step s2_cluster: <... completed>
|
|
|
|
step s2_reset: RESET ROLE;
|
|
|
|
|
|
|
|
starting permutation: s1_begin s1_lock_child s2_auth s2_cluster s1_commit s2_reset
|
|
|
|
step s1_begin: BEGIN;
|
|
|
|
step s1_lock_child: LOCK cluster_part_tab1 IN SHARE UPDATE EXCLUSIVE MODE;
|
2024-03-13 20:49:26 +01:00
|
|
|
step s2_auth: SET ROLE regress_cluster_part; SET client_min_messages = ERROR;
|
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
|
|
|
step s2_cluster: CLUSTER cluster_part_tab USING cluster_part_ind;
|
2022-04-26 06:41:17 +02:00
|
|
|
step s1_commit: COMMIT;
|
|
|
|
step s2_reset: RESET ROLE;
|
|
|
|
|
|
|
|
starting permutation: s1_begin s2_auth s1_lock_child s2_cluster s1_commit s2_reset
|
|
|
|
step s1_begin: BEGIN;
|
2024-03-13 20:49:26 +01:00
|
|
|
step s2_auth: SET ROLE regress_cluster_part; SET client_min_messages = ERROR;
|
2022-04-26 06:41:17 +02:00
|
|
|
step s1_lock_child: LOCK cluster_part_tab1 IN SHARE UPDATE EXCLUSIVE MODE;
|
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
|
|
|
step s2_cluster: CLUSTER cluster_part_tab USING cluster_part_ind;
|
2022-04-26 06:41:17 +02:00
|
|
|
step s1_commit: COMMIT;
|
|
|
|
step s2_reset: RESET ROLE;
|