On Fri, May 15, 2026 at 1:55 PM Fujii Masao <[email protected]> wrote: > On Fri, May 15, 2026 at 9:56 AM Etsuro Fujita <[email protected]> wrote: > > On Thu, May 14, 2026 at 11:30 PM Fujii Masao <[email protected]> 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. > > I think this inconsistency is confusing for users, especially because > if ANALYZE with restore_stats enabled fails to fetch remote statistics, > it falls back to sampling remote data using the table owner's user mapping. > > That means users enabling restore_stats may need to create two separate > user mappings: one for the table owner and another for the role executing > ANALYZE, just to handle the fallback case. This implicit switch in the user > mapping being used seems unnecessarily confusing to me.
I'm not sure users really care about using the two user mappings in the fallback case. But even if it's true, the case would be rather exceptional, so I don't think that that would be a big problem. Am I wrong? Anyway, I still don't think it's reasonable to use the owner's user mapping even when doing stats import, just for such an exceptional case. (Note: future work on stats import is to prevent fallback as much as possible, so the issue you are concerned about will be further reduced in the future.) Best regards, Etsuro Fujita
