[6x] Dump ALTER statements for child tables with different schemas #14962
Conversation
| @@ -26,7 +26,6 @@ static void check_gphdfs_external_tables(void); | |||
| static void check_gphdfs_user_roles(void); | |||
| static void check_unique_primary_constraint(void); | |||
| static void check_for_array_of_partition_table_types(ClusterInfo *cluster); | |||
| static void check_partition_schemas(void); | |||
There was a problem hiding this comment.
Note: Need to update the public facing docs for "Schemas on partitioned tables" as this is now removed.
kyeap-vmware
force-pushed
the
partition-schema-alter
branch
from
3a89048
to
4498070
Compare
ALTER TABLE name SET SCHEMA statements are dumped to support restore and upgrade of child partitions whose schemas are different than their parents. In binary upgrade mode, child partition oids are reserved using the parent's schema because that is where they initially land on creation.
Pg_dump now dumps ALTER TABLE name SET SCHEMA statements for child partitions. This means partition tables containing child partitions that belong to a schema different than it's parent can be dumped, restored, and upgraded. Remove the pg_upgrade check looking for this.
kyeap-vmware
force-pushed
the
partition-schema-alter
branch
from
4498070
to
9816484
Compare
|
Can't the change be validated in pg_upgrade test which run as part of ICW test itself if add the partition table with different schema object type as part of some test in ICW? |
Kinda, but we would have to modify and implement new testing logic in the pg_upgrade CI job then to do the full end-to-end testing of this change. Without this PR, it's a logical error where pg_upgrade would succeed and users would notice only later in post-upgrade testing of applications hitting those partitions. The pg_upgrade CI job only tests if pg_upgrade fails or succeeds. As part of the gpupgrade repository, post-upgrade testing is done to make sure objects are logically correct and still work as expected (e.g. post-upgrade query if the partition is still in the different schema and is usable). That's the divide between the GPDB and gpupgrade repositories in terms of testing. I think that's fine for now. |
To add a bit more context. There's a bit of a "chicken and egg" issue in terms of testing in the GPDB repo. That is, gpupgrade is independent of the GPDB repo and is not a dependency of GPDB. Because of this the pg_upgrade job in the GPDB CI basically does a crude implementation of gpupgrade in BASH which is "okay". Ideally we would use gpupgrade itself, but doing so adds a bit of a circular dependency. The pg_upgrade acceptance tests in the gpupgrade repo leverage gpupgrade to easily upgrade the cluster and expand on these tests. With much more thought and prototyping I am sure there are opportunities to improve pg_upgrade testing in the GPDB repo itself for faster and better feedback. |
|
Main aspect I am hearing is pg_upgrade test in GPDB uses pg_dump to perform the validation which itself is broken and hence insufficient to help validate the fix. This clearly showcases the testing/validation gap which exists in GPDB repository. Thanks. |
Dump ALTER statements for child tables with different schemas
pipeline: https://cm.ci.gpdb.pivotal.io/teams/main/pipelines/gpdb-cm-kyeap-vmware?group=all