[talmacschen-arch]

Problem

Restoring a database that contains foreign tables aborts their creation:

ERROR: server "sync_server" does not exist
ERROR: server "pg_gp6" does not exist

The backup's metadata.sql contains the CREATE FOREIGN TABLE statements but no CREATE SERVER for the servers they reference, so every such foreign table (and its ALTER FOREIGN TABLE ... OWNER) fails on restore.

Root cause

GetForeignServers filters with ExtensionFilterClause, i.e. it skips any foreign server that is an extension member (pg_depend deptype 'e'), on the assumption that CREATE EXTENSION will recreate it. A freshly created server is deptype 'n' and is kept — but a server that was added to an FDW extension with ALTER EXTENSION <fdw> ADD SERVER becomes deptype 'e' and is dropped from the dump. This is how the affected servers were created (a migration tool registered them under the FDW extension). Their foreign tables are ordinary objects (deptype 'n') and are still dumped, leaving the backup inconsistent: a dumped foreign table whose server was silently skipped cannot be restored.

Reproduced deterministically: a server is kept until ALTER EXTENSION ... ADD SERVER, after which oid NOT IN (pg_depend where deptype='e') becomes false and gpbackup omits it.

Fix

Also dump an extension-member server when a to-be-dumped foreign table depends on it, so the backup is self-contained. A server that no dumped foreign table references stays filtered, so genuinely extension-internal servers are still skipped and are not created twice on restore (no already exists).

Scope note: GetUserMappings was considered for the same treatment but left unchanged — a user mapping cannot be made an extension member (ALTER EXTENSION ... ADD USER MAPPING is a syntax error), so the deptype='e' clause never filters one in practice, and the affected backup contained no user mappings.

Note — is this gpbackup's bug?

Arguably the root cause is upstream: a migration tool should not ALTER EXTENSION ADD SERVER a server that user foreign tables depend on, since that makes the server undumpable; and pg_dump likewise skips extension-member objects, so by that standard gpbackup's old behavior is "not wrong". This PR takes the pragmatic position that a backup which dumps a foreign table must also dump the server that table needs, rather than produce an unrestorable backup. It only pulls in servers an exported foreign table actually references, so it does not broaden extension handling in general.

Testing

Added an integration test in the GetForeignServers block: a server added to an extension and referenced by a foreign table is returned, while an extension-member server that nothing references is not.

[talmacschen-arch]

Closing in favor of #129. Investigation with an end-to-end test showed the root cause is not GetForeignServers's extension filter (that function is never reached on Cloudberry) but a misplaced negation in retrieveFDWObjects that skips all FDW/server/user-mapping backup on Cloudberry. The new PR fixes that one line and adds an end-to-end regression test.