Technical Analysis: postgres_fdw User Mapping Inconsistency in ANALYZE with restore_stats

Core Problem

When ANALYZE is run on a foreign table managed by postgres_fdw, the system must establish a connection to the remote PostgreSQL server. This connection requires a user mapping — a catalog entry that maps a local PostgreSQL role to credentials on the remote server. The issue concerns which user mapping is selected depending on the restore_stats option.

The Two Code Paths in ANALYZE

PostgreSQL's ANALYZE on a foreign table via postgres_fdw has two mechanisms for gathering statistics:

1. Sampling (traditional path): The FDW fetches actual rows from the remote table, computes statistics locally. This path uses the foreign table owner's user mapping, following the established security model where the owner's privileges govern data access.

2. restore_stats (newer path): Instead of sampling remote data, the FDW queries pg_class and pg_stats on the remote server to import pre-computed statistics directly. This path uses the current user's (i.e., the role executing ANALYZE) user mapping.

Why This Matters Architecturally

The inconsistency creates a practical failure scenario:

• A DBA grants ANALYZE privilege on a foreign table to a non-owner role
• The foreign table owner has a valid user mapping; the non-owner role does not
• With restore_stats disabled: ANALYZE succeeds (uses owner's mapping)
• With restore_stats enabled: ANALYZE fails with "user mapping not found"
• If restore_stats partially fails and falls back to sampling, the system silently switches from the current user's mapping to the owner's mapping mid-operation

This means enabling restore_stats can break previously working ANALYZE operations, and the fallback behavior creates a confusing situation where two different user mappings may be needed.

Design Philosophy Disagreement

Fujii's Position (Consistency/Usability)

Fujii argues that:

• The behavioral difference is confusing to users who don't understand the internal distinction between sampling and stats import
• The fallback case is particularly problematic: if restore_stats fails, it falls back to sampling using the owner's mapping, meaning a single ANALYZE operation might use two different mappings
• Users may need to maintain two user mappings just to handle the fallback case
• A uniform policy (always use owner's mapping) is simpler to reason about

Etsuro Fujita's Position (Least Privilege Security)

Etsuro Fujita defends the current design as intentional, based on:

1. Principle of least privilege: Stats import only reads pg_class/pg_stats (catalog views), not actual table data. The owner's mapping typically has broader privileges than necessary for this operation.
2. Security conservatism: Using a more-privileged mapping (the owner's) when a less-privileged one suffices violates the principle of minimal authority.
3. The fallback case is exceptional: Future improvements to restore_stats aim to reduce fallback frequency, making the concern increasingly moot.

Technical Assessment

Etsuro Fujita's security argument has merit — querying remote catalog views is fundamentally different from querying actual table data, and using minimal privileges is sound practice. However, Fujii raises a legitimate usability concern about the operational complexity this creates.

The key architectural tension is between:

• Security model purity: Different operations should use the minimum required privileges
• Operational simplicity: A single ANALYZE command should have a predictable, uniform connection model

The current implementation essentially treats stats import as a separate operation from sampling in terms of its security context, even though from the user's perspective, both are sub-operations of a single ANALYZE command.

Implications of the Proposed Patch

Fujii's patch would:

• Make ANALYZE always use the foreign table owner's user mapping regardless of restore_stats
• Add regression tests covering both restore_stats enabled/disabled scenarios
• Simplify the user-facing mental model (one mapping needed: the owner's)
• Potentially use a more-privileged remote connection than strictly necessary for catalog queries

Current Status

The discussion appears to have reached an impasse. Etsuro Fujita (who appears to be the original author of the restore_stats feature) considers the current behavior intentional and well-reasoned, and does not find the consistency/usability argument compelling enough to override the security consideration. He also notes that future work will reduce fallback frequency, further diminishing the practical impact of the inconsistency.