These are the currently known issues and limitations identified in the WarehousePG Copy release. Where applicable, we have included workarounds to help you mitigate the impact of these issues. These issues are actively tracked and are planned for resolution in a future release.
- Support for password authentication:
whpg-copycurrently only supports password authentication through a password file. Use.pgpassor thePGPASSFILEenvironment variable to set a password for the connection. If you specify a password with thewhpg-copycommand or in the TOML-based configuration file, it will be ignored. - Views and materialized views:
whpg-copysupports the creation of both regular views and materialized views on the destination cluster. After the copy phase, it refreshes each materialized view, but only if every relation it depends on finished successfully. For a table dependency, that means the data copy completed. For a materialized view dependency, that means its own refresh succeeded. If a dependency fails,whpg-copyskips the refresh, along with any materialized views that depend on it, and you must manually executeREFRESH MATERIALIZED VIEWon the destination once the underlying data is in place. - Version compatibility: Migration is supported between clusters of the same version or when upgrading from WarehousePG 6.x to WarehousePG 7.x. However, downward migration from version 7.x to 6.x is not supported.
- Extensions with schema dependencies:
whpg-copydoesn't install extensions on the destination cluster automatically. If a table depends on an extension tied to a specific schema, such asvectororpostgis, install and create that extension on the destination cluster before runningwhpg-copy. Otherwise, the copy operation fails with an error similar totype "<schema>.<extension>" does not exist.