postgres_fdw: restore_stats uses current user's mapping instead of table owner's during ANALYZE

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: postgres_fdw: restore_stats uses current user's mapping instead of table owner's during ANALYZE
Date: 2026-05-14 14:30:13
Message-ID: CAHGQGwHJHwQ71DW2Ac0fSvGfPeNDF+T3kErLs20e9bu5O7j8+Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I found that ANALYZE on a foreign table with postgres_fdw uses different user
mappings depending on the restore_stats option. When restore_stats is disabled,
it uses the foreign table owner's user mapping to sample remote data. However,
when restore_stats is enabled, it instead uses the user mapping of the role
running ANALYZE to fetch remote statistics.

As a result, ANALYZE can fail with "user mapping not found" for users who are
allowed to analyze the foreign table but do not have their own user mapping,
even if the table owner has a valid one. Using different mappings depending on
restore_stats also seems confusing and inconsistent to me.

Was this behavior intentional?

The attached patch fixes this by making ANALYZE always use the foreign table
owner's user mapping, regardless of the restore_stats setting. It also adds
regression tests covering both restore_stats enabled and disabled cases.

Thoughts?

Regards,

--
Fujii Masao

Attachment Content-Type Size
v1-0001-postgres_fdw-Use-foreign-table-owner-s-user-mappi.patch application/octet-stream 4.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Malakhov 2026-05-14 15:05:41 Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table
Previous Message zengman 2026-05-14 14:07:16 Re: (SQL/PGQ) cache lookup failed for label