| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Several issues with postgres_fdw stats import |
| Date: | 2026-09-10 06:58:41 |
| Message-ID: | CAHGQGwH8+uDTwfohpck9v_9L3nwSWACbmC36JYRyqHd5xQN_OA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 | Ashutosh Bapat | 2026-09-10 06:59:20 | Re: PGQ catalog representation and pg_dump support |
| Previous Message | Jan Nidzwetzki | 2026-09-10 06:34:11 | Re: Add pg_nodiscard decorations to Bitmapset functions |