| From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: postgres_fdw: restore_stats uses current user's mapping instead of table owner's during ANALYZE |
| Date: | 2026-05-15 00:55:59 |
| Message-ID: | CAPmGK16vrt4aR1evS+mCWjgQCcn9jMxY8pHao-OTCnyESCShoA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Fujii-san,
On Thu, May 14, 2026 at 11:30 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> 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.
That's right.
> 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?
That's intentional. The reason for that is: 1) unlike sampling, stats
import only scans pg_class and pg_stats on the remote server, so there
is no need to use the owner's user mapping, and 2) considering that
the remote user mapped to the owner has stronger privileges in most
cases, it's secure to avoid doing so without a valid reason.
Sorry, I don't think that consistency is a good enough reason for that.
Thanks for reviewing this feature!
Best regards,
Etsuro Fujita
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2026-05-15 00:59:18 | Re: Track skipped tables during autovacuum and autoanalyze |
| Previous Message | Michael Paquier | 2026-05-14 23:40:26 | Re: Fix jsonpath .split_part() to honor silent mode |