Logical Replication extension for PostgreSQL 15, 14, 13, 12, 11, 10, 9.6, 9.5, 9.4 (Postgres), providing much faster replication than Slony, Bucardo or Londiste, as well as cross-version upgrades.
I'm attempting data migration from AlloyDB to standard PostgreSQL using pglogical.
My AlloyDB database contains the AlloyDB-specific "google_columnar_engine" extension.
During a pg_restore of my AlloyDB backup, followed by pglogical replication, I encounter the error "extension "google_columnar_engine" is not available".
I've verified that none of my application's tables, views, or functions directly use features of this extension except for the views that are created by AlloyDB in the public schema. However, removing the extension nor the views from AlloyDB is not possible due to database permissions.
Challenges:
My database backup is very large (2TB), making direct editing of the dump file impractical.
AlloyDB's internal views seem to depend on this extension, preventing backup modifications without deeper intervention.
Questions:
Exclude specific view objects during the replication process?
Configure pglogical to ignore extension-related statements during restore?
Environment
pglogical version: postgresql-16-pglogical
AlloyDB version (if known): PostgreSQL 14 compatible
PostgreSQL version (target): 16.2
Additional Notes:
I'm open to workarounds or alternative strategies.
I understand this might be a feature request rather than an immediate bug.
Description
I'm attempting data migration from AlloyDB to standard PostgreSQL using pglogical. My AlloyDB database contains the AlloyDB-specific "google_columnar_engine" extension.
During a pg_restore of my AlloyDB backup, followed by pglogical replication, I encounter the error "extension "google_columnar_engine" is not available".
I've verified that none of my application's tables, views, or functions directly use features of this extension except for the views that are created by AlloyDB in the public schema. However, removing the extension nor the views from AlloyDB is not possible due to database permissions.
Challenges:
Questions:
Environment
Additional Notes: