| From: | Osama Abdul Qader <osamaabdulqader(dot)cs(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: Several issues with postgres_fdw stats import |
| Date: | 2026-09-10 10:24:20 |
| Message-ID: | CAC+8b5hXjdNeKPpVg0TDcAYQTESPXLmTFPyPTB60JJObkSZ16g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
While reviewing the postgres_fdw statistics import implementation, I
noticed several potential issues:
1. *User-defined functions and privileges:* With stats import enabled,
some user-defined functions may be executed as the user running ANALYZE
rather than as the foreign table owner. This could potentially result in
functions being executed with unintended privileges, particularly when
ANALYZE is run by a superuser.
2. *COLLATE and old remote servers:* The generated query may send COLLATE
"C" to remote servers without checking their version. Since COLLATE is
only supported from PostgreSQL 9.1, this could break statistics import
against older servers. IMPORT FOREIGN SCHEMA already handles this
compatibility issue.
3. *n_distinct** is ignored:* The imported statistics path appears not
to apply the foreign table column's n_distinct option, whereas normal
ANALYZE applies it after collecting statistics.
4. *relpages** and different block sizes:* The remote relpages value
appears to be stored unchanged. If the local and remote servers use
different BLCKSZ values, this would result in an incorrect local page
count. The value should presumably be converted to local block units,
similar to how normal ANALYZE handles it.
Could these be addressed in the statistics import implementation?
On Thu, Sep 10, 2026 at 12:29 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Hi,
>
> postgres_fdw stats import seems to have several potential issues.
>
>
> (1) User-defined functions may be executed with unexpected privileges
>
> ANALYZE on a foreign table with import_stats disabled invokes
> user-defined functions (e.g., domain constraints) as the foreign table's
> owner. But, with import_stats enabled, they are invoked as the user
> running ANALYZE. So, if that user is a superuser, those functions would
> be run with superuser privileges. Could this be a security issue?
>
>
> (2) COLLATE is not supported by old remote servers
>
> Stats import sends COLLATE "C" to the remote server without checking
> its version, but COLLATE is supported only in v9.1 and later.
> The comment in deparse.c explicitly mentions this compatibility issue, and
> IMPORT FOREIGN SCHEMA disables collation import for remote servers older
> than v9.1.
>
> So, it seems stats import should handle this issue as well, e.g., either by
> avoiding COLLATE or by falling back to sampling.
>
>
> (3) n_distinct is ignored
>
> Stats import ignores the foreign table column's n_distinct option, whereas
> normal ANALYZE applies it after collecting statistics.
>
> IMO, n_distinct should also be applied to imported stats.
>
>
> (4) Imported relpages may use different block sizes
>
> Stats import stores the remote relpages value unchanged, whereas the
> normal ANALYZE uses pg_relation_size() divided by the local BLCKSZ to
> handle the case where the block sizes differ between the local and remote
> servers.
>
> We should convert the imported page count to local block units, for
> example?
>
> Regards,
>
> --
> Fujii Masao
>
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2026-09-10 10:24:37 | Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row |
| Previous Message | Alvaro Herrera | 2026-09-10 10:22:52 | Re: REPACK (CONCURRENTLY) fails when replica identity index is dropped |