agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedSeveral issues with postgres_fdw stats import
21+ messages / 6 participants
[nested] [flat]
* Several issues with postgres_fdw stats import
@ 2026-09-10 06:58 Fujii Masao <masao.fujii@gmail.com>
0 siblings, 2 replies; 21+ messages in thread
From: Fujii Masao @ 2026-09-10 06:58 UTC (permalink / raw)
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-10 10:24 Osama Abdul Qader <osamaabdulqader.cs@gmail.com>
parent: Fujii Masao <masao.fujii@gmail.com>
1 sibling, 1 reply; 21+ messages in thread
From: Osama Abdul Qader @ 2026-09-10 10:24 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
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.fujii@gmail.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
>
>
>
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-10 15:01 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Fujii Masao <masao.fujii@gmail.com>
1 sibling, 1 reply; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-10 15:01 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, Sep 10, 2026 at 3:59 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> 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?
Sorry, I don't follow this. Could you elaborate on it using an example?
> (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.
Good catch! I feel like just 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.
Rather than making the code complicated for that, I feel like just
copying the remote table's stats as-proposed, as in most cases, those
stats are generated on the remote server under the correct settings of
parameters like n_distcint. How about adding a note about that?
> (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?
Good point! Actually, this is a known issue in the normal ANALYZE:
/*
* Construct SELECT statement to acquire size in blocks of given relation.
*
* Note: we use local definition of block size, not remote definition.
* This is perhaps debatable.
*
* Note: pg_relation_size() exists in 8.1 and later.
*/
void
deparseAnalyzeSizeSql(StringInfo buf, Relation rel)
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-10 15:14 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Osama Abdul Qader <osamaabdulqader.cs@gmail.com>
0 siblings, 0 replies; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-10 15:14 UTC (permalink / raw)
To: Osama Abdul Qader <osamaabdulqader.cs@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, Sep 10, 2026 at 7:55 PM Osama Abdul Qader
<osamaabdulqader.cs@gmail.com> wrote:
> While reviewing the postgres_fdw statistics import implementation, I noticed several potential issues:
[snip]
> Could these be addressed in the statistics import implementation?
I noticed that your comments are exactly the same as Fujii-san. You
both used the same LLM for this?
Anyway, please check the email I sent just before. Thanks for reviewing!
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-10 15:46 Corey Huinker <corey.huinker@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 3 replies; 21+ messages in thread
From: Corey Huinker @ 2026-09-10 15:46 UTC (permalink / raw)
To: Etsuro Fujita <etsuro.fujita@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, Sep 10, 2026 at 11:02 AM Etsuro Fujita <etsuro.fujita@gmail.com>
wrote:
> On Thu, Sep 10, 2026 at 3:59 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> > 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?
>
> Sorry, I don't follow this. Could you elaborate on it using an example?
>
Me either. I think he's referring to generated columns, in which case the
generated column wouldn't have a corresponding source column, hence would
fail match_attrmap() and already falls back to sampling.
>
> > (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.
>
> Good catch! I feel like just falling back to sampling.
>
In other areas (pg_dump, for example) we're walking the minimum supported
version to v10, so I don't feel like we want to spend much effort
accommodating machines that went out of support > 12 years ago. The query
will error, it will fall back to sampling, and that's the right thing to do
in these cases, in my opinion.
The obvious counter-example are databases that are forks of postgres from
the 8.x era (Vertica, Redshift), neither of which have a pg_stats view, so
the queries are dead ends anyway. I could envision a future where those
databases are encouraged to add a pg_stats view with the stats
translated/synthesized to FDW-friendly values.
All of these things should already fall 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.
>
> Rather than making the code complicated for that, I feel like just
> copying the remote table's stats as-proposed, as in most cases, those
> stats are generated on the remote server under the correct settings of
> parameters like n_distcint. How about adding a note about that?
>
I agree. The user trusts the remote to have good stats, otherwise they
wouldn't use this option.
>
> From a cost calculation perspective, I think it's appropriate to use
> the imported relpages as-is, as it's used to estimate the cost for
> remote operations, not local ones, and thus we should actually instead
> fix the normal-ANALYZE handling to calculate the size based on the
> remote definition of block size.
>
+1
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-11 17:11 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Corey Huinker <corey.huinker@gmail.com>
2 siblings, 1 reply; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-11 17:11 UTC (permalink / raw)
To: Corey Huinker <corey.huinker@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Fri, Sep 11, 2026 at 12:46 AM Corey Huinker <corey.huinker@gmail.com> wrote:
> On Thu, Sep 10, 2026 at 11:02 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
>> On Thu, Sep 10, 2026 at 3:59 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>> > postgres_fdw stats import seems to have several potential issues.
>> > (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.
>>
>> Good catch! I feel like just falling back to sampling.
>
> In other areas (pg_dump, for example) we're walking the minimum supported version to v10, so I don't feel like we want to spend much effort accommodating machines that went out of support > 12 years ago.
+1
> The query will error, it will fall back to sampling, and that's the right thing to do in these cases, in my opinion.
No, it won't fall back; the syntax error on the remote server will
lead to an error on the local server, actually. That isn't great, so
I modified postgres_fdw to do the fallback. Patch attached.
> The obvious counter-example are databases that are forks of postgres from the 8.x era (Vertica, Redshift), neither of which have a pg_stats view, so the queries are dead ends anyway. I could envision a future where those databases are encouraged to add a pg_stats view with the stats translated/synthesized to FDW-friendly values.
Me too.
>> > (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.
>>
>> Rather than making the code complicated for that, I feel like just
>> copying the remote table's stats as-proposed, as in most cases, those
>> stats are generated on the remote server under the correct settings of
>> parameters like n_distcint. How about adding a note about that?
>
> I agree. The user trusts the remote to have good stats, otherwise they wouldn't use this option.
I modified postgres-fdw.sgml as well to mention that that option is
ignored, tweaking a phrase a bit.
Best regards,
Etsuro Fujita
Attachments:
[application/octet-stream] disallow-stats-import-from-old-servers.patch (4.5K, ../../CAPmGK16bNY6-1yExMOg8g5VZFq6U1icvtAodaY9MTSg-pt2O0w@mail.gmail.com/2-disallow-stats-import-from-old-servers.patch)
download | inline diff:
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index adfdb91cc20..1c0a1d25dcc 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -596,6 +596,7 @@ static bool fetch_remote_statistics(Relation relation,
const char *local_schemaname,
const char *local_relname,
ForeignTable *table,
+ ForeignServer *server,
RemoteStatsResults *remstats,
RemoteAttributeMapping **p_remattrmap,
int *p_attrcnt);
@@ -5763,7 +5764,7 @@ postgresImportForeignStatistics(Relation relation, List *va_cols, int elevel)
starttime = GetCurrentTimestamp();
ok = fetch_remote_statistics(relation, va_cols,
- schemaname, relname, table,
+ schemaname, relname, table, server,
&remstats, &remattrmap, &attrcnt);
if (ok)
@@ -5796,6 +5797,7 @@ fetch_remote_statistics(Relation relation,
const char *local_schemaname,
const char *local_relname,
ForeignTable *table,
+ ForeignServer *server,
RemoteStatsResults *remstats,
RemoteAttributeMapping **p_remattrmap,
int *p_attrcnt)
@@ -5912,6 +5914,19 @@ fetch_remote_statistics(Relation relation,
/* Try to get attribute stats if needed. */
if (attrcnt > 0)
{
+ /*
+ * The fetch_attstats query sends COLLATE "C" to the remote
+ * server; if it hasn't got it, fallback to sampling.
+ */
+ if (server_version_num < 90100)
+ {
+ ereport(WARNING,
+ errmsg("could not import statistics for foreign table \"%s.%s\" --- foreign server \"%s\" is too old to support attribute statistics import",
+ local_schemaname, local_relname,
+ server->servername));
+ goto fetch_cleanup;
+ }
+
/* Fetch attribute stats. */
remstats->att = attstats = fetch_attstats(conn,
server_version_num,
@@ -5987,6 +6002,9 @@ fetch_attstats(PGconn *conn, int server_version_num,
StringInfoData sql;
PGresult *res;
+ /* The caller guaranttees the remote server is v9.1 or later. */
+ Assert(server_version_num >= 90100);
+
initStringInfo(&sql);
appendStringInfoString(&sql,
"SELECT DISTINCT ON (attname COLLATE \"C\") attname,"
@@ -6030,18 +6048,11 @@ fetch_attstats(PGconn *conn, int server_version_num,
column_list);
/*
- * inherited is supported since Postgres 9.0
- *
- * Note that this is okay because for now, we support the case where the
- * remote table is partitioned, but not the case where it is inherited
- * (see fetch_remote_statistics()).
+ * inherited and COLLATE are supported since Postgres 9.0 and 9.1,
+ * respectively.
*/
- if (server_version_num >= 90000)
- appendStringInfoString(&sql,
- " ORDER BY attname COLLATE \"C\", inherited DESC");
- else
- appendStringInfoString(&sql,
- " ORDER BY attname COLLATE \"C\"");
+ appendStringInfoString(&sql,
+ " ORDER BY attname COLLATE \"C\", inherited DESC");
res = pgfdw_exec_query(conn, sql.data, NULL);
if (PQresultStatus(res) != PGRES_TUPLES_OK)
diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
index 80f79c017d6..fe4e6478e28 100644
--- a/doc/src/sgml/postgres-fdw.sgml
+++ b/doc/src/sgml/postgres-fdw.sgml
@@ -370,14 +370,15 @@ OPTIONS (ADD password_required 'false');
<para>
This option, which can be specified for a foreign table or a foreign
server, determines if <command>ANALYZE</command> on a foreign table
- will instead attempt to fetch the existing statistics for the foreign
- table on the remote server, and import those statistics directly to
- the local server. If the attempt failed, statistics are collected by
- row sampling on the foreign table.
+ will instead attempt to fetch the existing statistics for the remote
+ table, and import those statistics directly to the local server
+ (without applying the foreign table columns'
+ <literal>n_distinct</literal> option). If the attempt failed,
+ statistics are collected by row sampling on the foreign table.
This option is only useful if the remote table is one that can have
regular statistics (tables, not inherited, and materialized views).
When using this option, <emphasis>it is the user's responsibility
- </emphasis> to ensure that the existing statistics for the foreign
+ </emphasis> to ensure that the existing statistics for the remote
table are up-to-date.
The default is <literal>false</literal>.
</para>
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-11 20:53 Corey Huinker <corey.huinker@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Corey Huinker @ 2026-09-11 20:53 UTC (permalink / raw)
To: Etsuro Fujita <etsuro.fujita@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
>
>
> No, it won't fall back; the syntax error on the remote server will
> lead to an error on the local server, actually. That isn't great, so
> I modified postgres_fdw to do the fallback. Patch attached.
>
My mistake. The patch looks good. Clearly there's no sufficiently venerable
buildfarm animal that could have detected this, or else we would have found
it sooner, and it's hard to justify supporting it if we cant test it.
>
> > The obvious counter-example are databases that are forks of postgres
> from the 8.x era (Vertica, Redshift), neither of which have a pg_stats
> view, so the queries are dead ends anyway. I could envision a future where
> those databases are encouraged to add a pg_stats view with the stats
> translated/synthesized to FDW-friendly values.
>
> Me too.
>
It's a bummer that this change will make it slightly harder to do so, but
the chance of redshift or vertica doing such a thing is very low, and if
they did they'd probably bump their server_version_number along with the
change.
> e user trusts the remote to have good stats, otherwise they wouldn't use
> this option.
>
> I modified postgres-fdw.sgml as well to mention that that option is
> ignored, tweaking a phrase a bit.
>
>
+1. Applies clean. Passes tests tho obviously the test we needed all along
would have been on a very old buildfarm animal. The wording of the
documentation change is clear.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-14 11:12 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Corey Huinker <corey.huinker@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-14 11:12 UTC (permalink / raw)
To: Corey Huinker <corey.huinker@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Sat, Sep 12, 2026 at 5:53 AM Corey Huinker <corey.huinker@gmail.com> wrote:
>> No, it won't fall back; the syntax error on the remote server will
>> lead to an error on the local server, actually. That isn't great, so
>> I modified postgres_fdw to do the fallback. Patch attached.
>
> My mistake. The patch looks good. Clearly there's no sufficiently venerable buildfarm animal that could have detected this, or else we would have found it sooner, and it's hard to justify supporting it if we cant test it.
>> e user trusts the remote to have good stats, otherwise they wouldn't use this option.
>>
>> I modified postgres-fdw.sgml as well to mention that that option is
>> ignored, tweaking a phrase a bit.
>
> +1. Applies clean. Passes tests tho obviously the test we needed all along would have been on a very old buildfarm animal. The wording of the documentation change is clear.
Pushed/backpatched.
The regression test just uses a loopback server, so it only tests this
feature against the same version... I think it would be nice if we
could do so against old versions, but that would need a new testing
framework that can also support other features like IMPORT FOREIGN
SCHEMA, so I'd like to leave that for future work.
Thanks for looking!
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-15 08:52 Fujii Masao <masao.fujii@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Fujii Masao @ 2026-09-15 08:52 UTC (permalink / raw)
To: Etsuro Fujita <etsuro.fujita@gmail.com>; +Cc: Corey Huinker <corey.huinker@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Mon, Sep 14, 2026 at 8:12 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> Pushed/backpatched.
Thanks for working on this issue!
When I used v11 as the remote server, stats import via postgres_fdw
resulted in the following error. I think this should be addressed as well.
ERROR: collations are not supported by type name
CONTEXT: remote SQL command: SELECT DISTINCT ON (attname COLLATE "C")
attname, null_frac, avg_width, n_distinct, most_common_vals,
most_common_freqs, histogram_bounds, correlation, most_common_elems,
most_common_elem_freqs, elem_count_histogram, NULL, NULL, NULL FROM
pg_catalog.pg_stats WHERE schemaname = 'public' AND tablename = 't'
AND attname = ANY(ARRAY['i', 'j']) ORDER BY attname COLLATE "C",
inherited DESC
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-15 11:31 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Fujii Masao <masao.fujii@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-15 11:31 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: Corey Huinker <corey.huinker@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Sep 15, 2026 at 5:52 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> When I used v11 as the remote server, stats import via postgres_fdw
> resulted in the following error. I think this should be addressed as well.
>
> ERROR: collations are not supported by type name
> CONTEXT: remote SQL command: SELECT DISTINCT ON (attname COLLATE "C")
> attname, null_frac, avg_width, n_distinct, most_common_vals,
> most_common_freqs, histogram_bounds, correlation, most_common_elems,
> most_common_elem_freqs, elem_count_histogram, NULL, NULL, NULL FROM
> pg_catalog.pg_stats WHERE schemaname = 'public' AND tablename = 't'
> AND attname = ANY(ARRAY['i', 'j']) ORDER BY attname COLLATE "C",
> inherited DESC
Reproduced here. Will fix.
I was thinking this lacks testing against old servers, so thanks for
the testing and report!
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-16 10:25 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-16 10:25 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@gmail.com>; +Cc: Corey Huinker <corey.huinker@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Sep 15, 2026 at 8:31 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Tue, Sep 15, 2026 at 5:52 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> > When I used v11 as the remote server, stats import via postgres_fdw
> > resulted in the following error. I think this should be addressed as well.
> >
> > ERROR: collations are not supported by type name
> > CONTEXT: remote SQL command: SELECT DISTINCT ON (attname COLLATE "C")
> > attname, null_frac, avg_width, n_distinct, most_common_vals,
> > most_common_freqs, histogram_bounds, correlation, most_common_elems,
> > most_common_elem_freqs, elem_count_histogram, NULL, NULL, NULL FROM
> > pg_catalog.pg_stats WHERE schemaname = 'public' AND tablename = 't'
> > AND attname = ANY(ARRAY['i', 'j']) ORDER BY attname COLLATE "C",
> > inherited DESC
>
> Reproduced here. Will fix.
As the error message says, the cause of this is that the name type
isn't collatable in v11. It was made so in v12, so I fixed this by
just s/attname COLLATE "C"/attname::text COLLATE "C"/ to the query
generated for v11 or older.
Also, I fixed another bug in the same function: a typo in the if-test
to check whether the remote server is v9.2 or later. The if-test in
Corey's original version was correct, so that's my fault when updating
it to the current version. :palmface:
Attached is a patch for that.
Best regards,
Etsuro Fujita
Attachments:
[application/octet-stream] fix-oversights-in-fetch_attstats.patch (1.9K, ../../CAPmGK14nR9_DtvMubWxpH0_GVxQxvjzbdEdUD73E6PB6=BZ6QQ@mail.gmail.com/2-fix-oversights-in-fetch_attstats.patch)
download | inline diff:
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index d890bc02b77..3ea0682af44 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -6007,8 +6007,16 @@ fetch_attstats(PGconn *conn, int server_version_num,
Assert(server_version_num >= 90100);
initStringInfo(&sql);
+
+ /* Type name is collatable since Postgres 12 */
+ if (server_version_num >= 120000)
+ appendStringInfoString(&sql,
+ "SELECT DISTINCT ON (attname COLLATE \"C\") attname,");
+ else
+ appendStringInfoString(&sql,
+ "SELECT DISTINCT ON (attname::text COLLATE \"C\") attname,");
+
appendStringInfoString(&sql,
- "SELECT DISTINCT ON (attname COLLATE \"C\") attname,"
" null_frac,"
" avg_width,"
" n_distinct,"
@@ -6018,7 +6026,7 @@ fetch_attstats(PGconn *conn, int server_version_num,
" correlation,");
/* Elements stats are supported since Postgres 9.2 */
- if (server_version_num >= 92000)
+ if (server_version_num >= 90200)
appendStringInfoString(&sql,
" most_common_elems,"
" most_common_elem_freqs,"
@@ -6049,11 +6057,15 @@ fetch_attstats(PGconn *conn, int server_version_num,
column_list);
/*
- * inherited and COLLATE are supported since Postgres 9.0 and 9.1,
- * respectively.
+ * Type name is collatable since Postgres 12 (inherited and COLLATE are
+ * supported since Postgres 9.0 and 9.1, respectively)
*/
- appendStringInfoString(&sql,
- " ORDER BY attname COLLATE \"C\", inherited DESC");
+ if (server_version_num >= 120000)
+ appendStringInfoString(&sql,
+ " ORDER BY attname COLLATE \"C\", inherited DESC");
+ else
+ appendStringInfoString(&sql,
+ " ORDER BY attname::text COLLATE \"C\", inherited DESC");
res = pgfdw_exec_query(conn, sql.data, NULL);
if (PQresultStatus(res) != PGRES_TUPLES_OK)
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-16 17:58 Corey Huinker <corey.huinker@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Corey Huinker @ 2026-09-16 17:58 UTC (permalink / raw)
To: Etsuro Fujita <etsuro.fujita@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, Sep 16, 2026 at 6:25 AM Etsuro Fujita <etsuro.fujita@gmail.com>
wrote:
> On Tue, Sep 15, 2026 at 8:31 PM Etsuro Fujita <etsuro.fujita@gmail.com>
> wrote:
> > On Tue, Sep 15, 2026 at 5:52 PM Fujii Masao <masao.fujii@gmail.com>
> wrote:
> > > When I used v11 as the remote server, stats import via postgres_fdw
> > > resulted in the following error. I think this should be addressed as
> well.
> > >
> > > ERROR: collations are not supported by type name
> > > CONTEXT: remote SQL command: SELECT DISTINCT ON (attname COLLATE "C")
> > > attname, null_frac, avg_width, n_distinct, most_common_vals,
> > > most_common_freqs, histogram_bounds, correlation, most_common_elems,
> > > most_common_elem_freqs, elem_count_histogram, NULL, NULL, NULL FROM
> > > pg_catalog.pg_stats WHERE schemaname = 'public' AND tablename = 't'
> > > AND attname = ANY(ARRAY['i', 'j']) ORDER BY attname COLLATE "C",
> > > inherited DESC
> >
> > Reproduced here. Will fix.
>
> As the error message says, the cause of this is that the name type
> isn't collatable in v11. It was made so in v12, so I fixed this by
> just s/attname COLLATE "C"/attname::text COLLATE "C"/ to the query
> generated for v11 or older.
>
+1
>
> Also, I fixed another bug in the same function: a typo in the if-test
> to check whether the remote server is v9.2 or later. The if-test in
> Corey's original version was correct, so that's my fault when updating
> it to the current version. :palmface:
>
+1. This is a good argument for #define-ing the relevant server version
numbers going forward.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-18 09:23 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Corey Huinker <corey.huinker@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-18 09:23 UTC (permalink / raw)
To: Corey Huinker <corey.huinker@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, Sep 17, 2026 at 2:58 AM Corey Huinker <corey.huinker@gmail.com> wrote:
> On Wed, Sep 16, 2026 at 6:25 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
>> As the error message says, the cause of this is that the name type
>> isn't collatable in v11. It was made so in v12, so I fixed this by
>> just s/attname COLLATE "C"/attname::text COLLATE "C"/ to the query
>> generated for v11 or older.
>
> +1
>> Also, I fixed another bug in the same function: a typo in the if-test
>> to check whether the remote server is v9.2 or later.
> +1.
Pushed/backpatched.
> This is a good argument for #define-ing the relevant server version numbers going forward.
Seams like a good idea.
Thanks for looking!
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-18 17:37 Nathan Bossart <nathandbossart@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Nathan Bossart @ 2026-09-18 17:37 UTC (permalink / raw)
To: Etsuro Fujita <etsuro.fujita@gmail.com>; +Cc: Corey Huinker <corey.huinker@gmail.com>; Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Fri, Sep 18, 2026 at 06:23:04PM +0900, Etsuro Fujita wrote:
> Pushed/backpatched.
Can the open item for this one be marked as resolved?
--
nathan
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-19 10:32 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-19 10:32 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Corey Huinker <corey.huinker@gmail.com>; Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Sat, Sep 19, 2026 at 2:37 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> Can the open item for this one be marked as resolved?
Sorry, I forgot to mention about that. We have resolved two of the
four reported issues, but these are still open:
(1) User-defined functions may be executed with unexpected privileges
(4) Imported relpages may use different block sizes
For #1, I will address it with a patch shared by Noah off-list. For
#4, I will propose a document-only patch to address it. I will send
the proposals for these separately early next week.
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-22 11:26 Pavel Luzanov <p.luzanov@postgrespro.ru>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Pavel Luzanov @ 2026-09-22 11:26 UTC (permalink / raw)
To: Etsuro Fujita <etsuro.fujita@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; +Cc: Corey Huinker <corey.huinker@gmail.com>; Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Hi,
Commit 9a08585e8 renamed option "restore_stats" to "import_stats".
But I still see the "restore_stats" option in the v19 documentation. [1]
Is it intended only for v20?
1.
https://www.postgresql.org/docs/19/postgres-fdw.html#POSTGRES-FDW-OPTIONS-COST-ESTIMATION
--
Pavel Luzanov
Postgres Professional: https://postgrespro.com
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-22 11:35 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Corey Huinker <corey.huinker@gmail.com>
2 siblings, 0 replies; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-22 11:35 UTC (permalink / raw)
To: Corey Huinker <corey.huinker@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Noah Misch <noah@leadboat.com>
I added Noah in CC.
On Fri, Sep 11, 2026 at 12:46 AM Corey Huinker <corey.huinker@gmail.com> wrote:
> On Thu, Sep 10, 2026 at 11:02 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
>> On Thu, Sep 10, 2026 at 3:59 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>> > 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?
>>
>> Sorry, I don't follow this. Could you elaborate on it using an example?
>
> Me either. I think he's referring to generated columns, in which case the generated column wouldn't have a corresponding source column, hence would fail match_attrmap() and already falls back to sampling.
Here is an example provided by Noah, which doesn't involve
user-defined functions, but causes a security issue:
CREATE SERVER loopback FOREIGN DATA WRAPPER postgres_fdw OPTIONS
(dbname 'postgres');
CREATE USER MAPPING FOR CURRENT_USER SERVER loopback;
DROP ROLE IF EXISTS regress_ftowner;
CREATE ROLE regress_ftowner NOSUPERUSER;
GRANT USAGE ON FOREIGN SERVER loopback TO regress_ftowner;
GRANT CREATE ON SCHEMA public TO regress_ftowner;
CREATE TABLE secret (s text);
REVOKE ALL ON secret FROM PUBLIC;
INSERT INTO secret SELECT 'hunter2' FROM generate_series(1, 10);
ANALYZE secret;
SET ROLE regress_ftowner;
CREATE FOREIGN TABLE ft_secret (s text) SERVER loopback
OPTIONS (table_name 'secret', import_stats 'true');
-- the owner can neither read secret nor reach the remote server
SELECT * FROM ft_secret;
ERROR: user mapping not found for user "regress_ftowner", server "loopback"
-- which is good, BUT import_stats discloses data the owner cannot read
RESET ROLE;
ANALYZE ft_secret;
SET ROLE regress_ftowner;
SELECT most_common_vals FROM pg_stats WHERE tablename = 'ft_secret';
most_common_vals
------------------
{hunter2}
(1 row)
He provided a fix for this as well, which I'm attaching. The fix
addresses it by switching the userid to the foreign-table owner's
userid in analyze.c before calling ImportForeignStatistics(). I think
the fix is also reasonable in that it makes the identity handling
consistent between the sampling/import methods. So I will push and
back-patch the fix if no objections from others.
Best regards,
Etsuro Fujita
Attachments:
[application/octet-stream] fix-stats-import-priv-handling.patch (2.2K, ../../CAPmGK16jVk+i2KMkkgR9ajoPdaUAinvcspkk5Bc6urbo2xYTMQ@mail.gmail.com/2-fix-stats-import-priv-handling.patch)
download | inline diff:
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index fbe01fdde85..42a704344b8 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -5832,11 +5832,10 @@ fetch_remote_statistics(Relation relation,
}
/*
- * Get connection to the foreign server. Connection manager will
- * establish new connection if necessary.
- *
- * Note that unlike the sampling case, we only query pg_class and
- * pg_stats, so we do the remote access as the current user.
+ * Get the connection to use. We do the remote access as the table's
+ * owner. Note that unlike AnalyzeForeignTable(), the core code would
+ * already have switched us to the table's owner, before we are called
+ * from ImportForeignStatistics().
*/
user = GetUserMapping(GetUserId(), table->serverid);
conn = GetConnection(user, false, NULL);
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index c05f9f50e43..40b0e23ca2e 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -228,10 +228,32 @@ analyze_rel(Oid relid, RangeVar *relation,
fdwroutine = GetFdwRoutineForRelation(onerel, false);
- if (fdwroutine->ImportForeignStatistics != NULL &&
- fdwroutine->ImportForeignStatistics(onerel, va_cols, elevel))
- stats_imported = true;
- else
+ if (fdwroutine->ImportForeignStatistics != NULL)
+ {
+ Oid save_userid;
+ int save_sec_context;
+ int save_nestlevel;
+
+ /*
+ * Switch to the table owner's userid, as in the sampling method.
+ * Also lock down security-restricted operations and arrange to
+ * make GUC variable changes local to this command.
+ */
+ GetUserIdAndSecContext(&save_userid, &save_sec_context);
+ SetUserIdAndSecContext(onerel->rd_rel->relowner,
+ save_sec_context | SECURITY_RESTRICTED_OPERATION);
+ save_nestlevel = NewGUCNestLevel();
+ RestrictSearchPath();
+
+ stats_imported = fdwroutine->ImportForeignStatistics(onerel,
+ va_cols,
+ elevel);
+
+ AtEOXact_GUC(false, save_nestlevel);
+ SetUserIdAndSecContext(save_userid, save_sec_context);
+ }
+
+ if (!stats_imported)
{
bool ok = false;
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-22 11:38 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Corey Huinker <corey.huinker@gmail.com>
2 siblings, 0 replies; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-22 11:38 UTC (permalink / raw)
To: Corey Huinker <corey.huinker@gmail.com>; +Cc: Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Fri, Sep 11, 2026 at 12:46 AM Corey Huinker <corey.huinker@gmail.com> wrote:
> On Thu, Sep 10, 2026 at 11:02 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
>> From a cost calculation perspective, I think it's appropriate to use
>> the imported relpages as-is, as it's used to estimate the cost for
>> remote operations, not local ones, and thus we should actually instead
>> fix the normal-ANALYZE handling to calculate the size based on the
>> remote definition of block size.
>
> +1
I expanded a comment to mention this. Attached is a patch for that.
I will push and back-patch the patch if no objections.
Best regards,
Etsuro Fujita
Attachments:
[application/octet-stream] improve-stats-import-comments.patch (710B, ../../CAPmGK14OBMkMEkanHdA9+JdrZLGzfNRcEVmb6K4DtDe_CTTTqw@mail.gmail.com/2-improve-stats-import-comments.patch)
download | inline diff:
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index 42a704344b8..3bbc4493925 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -5954,7 +5954,10 @@ fetch_remote_statistics(Relation relation,
/*
* If the remote table is partitioned, import relpages = 0, to match the
- * sampling case.
+ * sampling case. Otherwise, import the relpages value as-is even if the
+ * remote definition of block size was different from the local one. Note
+ * that this is fine because it's only used for costing remote operations
+ * on the foreign table.
*/
if (relkind == RELKIND_PARTITIONED_TABLE)
remstats->relpages = 0;
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-22 11:50 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Pavel Luzanov <p.luzanov@postgrespro.ru>
0 siblings, 1 reply; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-22 11:50 UTC (permalink / raw)
To: Pavel Luzanov <p.luzanov@postgrespro.ru>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Corey Huinker <corey.huinker@gmail.com>; Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Sep 22, 2026 at 8:26 PM Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
> Commit 9a08585e8 renamed option "restore_stats" to "import_stats".
> But I still see the "restore_stats" option in the v19 documentation. [1]
>
> Is it intended only for v20?
The change was made for beta4, released this week, but the
documentation is still for beta3.
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-23 15:11 Nathan Bossart <nathandbossart@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 1 reply; 21+ messages in thread
From: Nathan Bossart @ 2026-09-23 15:11 UTC (permalink / raw)
To: Etsuro Fujita <etsuro.fujita@gmail.com>; +Cc: Pavel Luzanov <p.luzanov@postgrespro.ru>; Corey Huinker <corey.huinker@gmail.com>; Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Sep 22, 2026 at 08:50:46PM +0900, Etsuro Fujita wrote:
> On Tue, Sep 22, 2026 at 8:26 PM Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
>> Commit 9a08585e8 renamed option "restore_stats" to "import_stats".
>> But I still see the "restore_stats" option in the v19 documentation. [1]
>>
>> Is it intended only for v20?
>
> The change was made for beta4, released this week, but the
> documentation is still for beta3.
Can the open item for this one be marked resolved?
--
nathan
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: Several issues with postgres_fdw stats import
@ 2026-09-23 23:58 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 0 replies; 21+ messages in thread
From: Etsuro Fujita @ 2026-09-23 23:58 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Pavel Luzanov <p.luzanov@postgrespro.ru>; Corey Huinker <corey.huinker@gmail.com>; Fujii Masao <masao.fujii@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, Sep 24, 2026 at 12:11 AM Nathan Bossart
<nathandbossart@gmail.com> wrote:
> Can the open item for this one be marked resolved?
Yes, I think so; I will push two remaining patches by this weekend at
the latest.
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 21+ messages in thread
end of thread, other threads:[~2026-09-23 23:58 UTC | newest]
Thread overview: 21+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-10 06:58 Several issues with postgres_fdw stats import Fujii Masao <masao.fujii@gmail.com>
2026-09-10 10:24 ` Osama Abdul Qader <osamaabdulqader.cs@gmail.com>
2026-09-10 15:14 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-10 15:01 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-10 15:46 ` Corey Huinker <corey.huinker@gmail.com>
2026-09-11 17:11 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-11 20:53 ` Corey Huinker <corey.huinker@gmail.com>
2026-09-14 11:12 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-15 08:52 ` Fujii Masao <masao.fujii@gmail.com>
2026-09-15 11:31 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-16 10:25 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-16 17:58 ` Corey Huinker <corey.huinker@gmail.com>
2026-09-18 09:23 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-18 17:37 ` Nathan Bossart <nathandbossart@gmail.com>
2026-09-19 10:32 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-22 11:26 ` Pavel Luzanov <p.luzanov@postgrespro.ru>
2026-09-22 11:50 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-23 15:11 ` Nathan Bossart <nathandbossart@gmail.com>
2026-09-23 23:58 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-22 11:35 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2026-09-22 11:38 ` Etsuro Fujita <etsuro.fujita@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox