Skip to main content

pg_dump_invocation

Function pg_dump_invocation 

Source
pub fn pg_dump_invocation(
    conn: &PgConnection,
    data_only: bool,
    server_version_num: &str,
    exclude_extensions: &[String],
    no_publications: bool,
) -> SqlInvocation
Expand description

Build the pg_dump invocation for an EXPORT. Custom format (-Fc): compressed and the natural input to pg_restore. --data-only emits only the data AND EXCLUDES the host-owned migration ledger’s rows (boatramp_migrations.*): the ledger is a schema INSIDE the tenant database, so a plain --data-only dump would carry its rows and a pg_restore --data-only --exit-on-error into the already-migrated target (the matching-fingerprint case — the PRIMARY use) would hit a primary-key conflict on the ledger and abort. Excluding it keeps the target’s own boatramp_migrations ledger intact (the stated property).

§Extension-comment handling (--no-comments vs --exclude-extension)

The atomic shadow-restore applies the dump as a NON-SUPERUSER ephemeral role (the inc2 RCE-on-import guard), which cannot run a COMMENT ON EXTENSION <ext> — that is OWNER-only, and a superuser pre-creates the operator trusted-extension allowlist (e.g. pgvector, whose control file sets no trusted = true) in the shadow, so those extensions are SUPERUSER-owned there. So a dump carrying COMMENT ON EXTENSION <allowlisted> would FAIL the non-superuser apply. Two ways to keep it out of the dump:

  • PG16 and below (no --exclude-extension): the blunt --no-comments — strips ALL comments. Object (table/column) comments are then NOT carried through a project export; an accepted FIDELITY limitation, not a correctness one.
  • PG17+: --exclude-extension=<ext> per shadow-pre-created extension — drops just those extensions (their CREATE EXTENSION + COMMENT ON EXTENSION) from the dump, which the shadow already holds, so ALL OTHER comments (table/column/…) survive. The dump’s objects that USE the extension (e.g. a vector-typed column) still dump fine — the type exists in the pre-created shadow. This narrowing applies ONLY where the shadow pre-creates the extensions (the chunked managed path): pass exclude_extensions empty for the sidecar/ external path, whose restore NEEDS the dump’s own CREATE EXTENSION (we never pre-create on an operator’s own DB), so it stays on --no-comments regardless of version.

A dump naming an extension NOT in exclude_extensions is unaffected: on the shadow path a non-allowlisted CREATE EXTENSION still fails-closed under the non-superuser apply (correct — an untrusted bundle must not install an arbitrary extension), the same outcome in both modes.