pgsql: Fix dependency handling of column drop with partitioned tables
Fix dependency handling of column drop with partitioned tables
When dropping a column on a partitioned table which has one or more
partitioned indexes, the operation was failing as dependencies with
partitioned indexes using the column dropped were not getting removed in
a way consistent with the columns involved across all the relations part
of an inheritance tree.
This commit refactors the code executing column drop so as all the
columns from an inheritance tree to remove are gathered first, and
dropped all at the end. This way, we let the dependency machinery sort
out by itself the deletion of all the columns with the partitioned
indexes across a partition tree.
This issue has been introduced by 1d92a0c, so backpatch down to
REL_12_STABLE.
Author: Amit Langote, Michael Paquier
Reviewed-by: Álvaro Herrera, Ashutosh Sharma
Discussion: /messages/by-id/CA+HiwqE9kuBsZ3b5pob2-cvE8ofzPWs-og+g8bKKGnu6b4-yTQ@mail.gmail.com
Backpatch-through: 12
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/3a58c5f1464bf5bb5e602477222da88ee201392c
Modified Files
--------------
src/backend/commands/tablecmds.c | 41 +++++++++++++++++------
src/test/regress/expected/indexing.out | 61 ++++++++++++++++++++++++++++++++++
src/test/regress/sql/indexing.sql | 21 ++++++++++++
3 files changed, 113 insertions(+), 10 deletions(-)
On Sun, Oct 13, 2019 at 08:54:19AM +0000, Michael Paquier wrote:
Fix dependency handling of column drop with partitioned tables
When dropping a column on a partitioned table which has one or more
partitioned indexes, the operation was failing as dependencies with
partitioned indexes using the column dropped were not getting removed in
a way consistent with the columns involved across all the relations part
of an inheritance tree.This commit refactors the code executing column drop so as all the
columns from an inheritance tree to remove are gathered first, and
dropped all at the end. This way, we let the dependency machinery sort
out by itself the deletion of all the columns with the partitioned
indexes across a partition tree.
rhinoceros is unhappy with this one in the sepgsql tests as this has
moved a cascading drop notice when droping a column:
ALTER TABLE regtest_table DROP COLUMN y;
LOG: SELinux: allowed { drop }
scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0
tcontext=unconfined_u:object_r:sepgsql_table_t:s0 tclass=db_column
name="regtest_schema.regtest_table.y"
ALTER TABLE regtest_ptable DROP COLUMN q CASCADE;
+NOTICE: drop cascades to view regtest_pview
LOG: SELinux: allowed { drop }
scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0
tcontext=unconfined_u:object_r:sepgsql_table_t:s0 tclass=db_column
name="regtest_schema.regtest_ptable_ones.q"
LOG: SELinux: allowed { drop }
scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0
tcontext=unconfined_u:object_r:sepgsql_table_t:s0 tclass=db_column
name="regtest_schema.regtest_ptable_tens.q"
-NOTICE: drop cascades to view regtest_pviewIt seems to me that it would be fine to just update the output to
the newly-expected behavior. Any opinions?
--
Michael
Michael Paquier <michael@paquier.xyz> writes:
On Sun, Oct 13, 2019 at 08:54:19AM +0000, Michael Paquier wrote:
Fix dependency handling of column drop with partitioned tables
rhinoceros is unhappy with this one in the sepgsql tests as this has
moved a cascading drop notice when droping a column:
...
It seems to me that it would be fine to just update the output to
the newly-expected behavior. Any opinions?
Yeah, that sounds good to me.
regards, tom lane