pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #16807: Assert failed in postgres_fdw/estimate_path_cost_size with an empty foreign table
6+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2021-02-05 5e7fa189ee 984384129b postgres_fdw: Fix assertion in estimate_path_cost_size().
* BUG #16807: Assert failed in postgres_fdw/estimate_path_cost_size with an empty foreign table
@ 2021-01-05 18:00 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 6+ messages in thread
From: PG Bug reporting form @ 2021-01-05 18:00 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: exclusion@gmail.com
The following bug has been logged on the website:
Bug reference: 16807
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 13.1
Operating system: Ubuntu 20.04
Description:
When executing the following query:
CREATE EXTENSION postgres_fdw;
DO $d$
BEGIN
EXECUTE $$CREATE SERVER loopback FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (dbname '$$||current_database()||$$',
port '$$||current_setting('port')||$$'
)$$;
END;
$d$;
CREATE USER MAPPING FOR CURRENT_USER SERVER loopback;
CREATE TABLE t1 (c1 int NOT NULL);
CREATE FOREIGN TABLE ft1 (c1 int NOT NULL) SERVER loopback OPTIONS
(schema_name 'public', table_name 't1');
INSERT INTO t1 SELECT id FROM generate_series(1, 100) id;
DELETE FROM t1;
ANALYZE ft1;
EXPLAIN
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft1 t2 ON (t1.c1 = t2.c1) ORDER BY
t1.c1, t2.c1;
The assert-enabled server crashes with the stacktrace:
Core was generated by `postgres: law contrib_regression [local] EXPLAIN
'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007efc3d7fa859 in __GI_abort () at abort.c:79
#2 0x000055d6c447c083 in ExceptionalCondition (
conditionName=conditionName@entry=0x7efc3dd795eb "fpinfo->retrieved_rows
>= 1",
errorType=errorType@entry=0x7efc3dd784e5 "FailedAssertion",
fileName=fileName@entry=0x7efc3dd7959c "postgres_fdw.c",
lineNumber=lineNumber@entry=2810) at assert.c:67
#3 0x00007efc3dd6e5e5 in estimate_path_cost_size
(root=root@entry=0x55d6c5e9b250,
foreignrel=foreignrel@entry=0x55d6c5e8b760,
param_join_conds=param_join_conds@entry=0x0,
pathkeys=pathkeys@entry=0x55d6c5e9e258, fpextra=fpextra@entry=0x0,
p_rows=p_rows@entry=0x7ffcc2b6d320,
p_width=0x7ffcc2b6d31c, p_startup_cost=0x7ffcc2b6d328,
p_total_cost=0x7ffcc2b6d330) at postgres_fdw.c:2810
#4 0x00007efc3dd6fdda in add_paths_with_pathkeys_for_rel
(root=root@entry=0x55d6c5e9b250,
rel=rel@entry=0x55d6c5e8b760, epq_path=epq_path@entry=0x0) at
postgres_fdw.c:5278
#5 0x00007efc3dd72c8e in postgresGetForeignPaths (root=0x55d6c5e9b250,
baserel=0x55d6c5e8b760,
foreigntableid=<optimized out>) at postgres_fdw.c:994
#6 0x000055d6c4247d1f in set_foreign_pathlist
(root=root@entry=0x55d6c5e9b250, rel=rel@entry=0x55d6c5e8b760,
rte=rte@entry=0x55d6c5d97bf0) at allpaths.c:927
#7 0x000055d6c424b78e in set_rel_pathlist (root=root@entry=0x55d6c5e9b250,
rel=0x55d6c5e8b760, rti=rti@entry=1,
rte=0x55d6c5d97bf0) at allpaths.c:490
#8 0x000055d6c424b8ad in set_base_rel_pathlists
(root=root@entry=0x55d6c5e9b250) at allpaths.c:352
#9 0x000055d6c424bf95 in make_one_rel (root=root@entry=0x55d6c5e9b250,
joinlist=joinlist@entry=0x55d6c5e9cbd0)
at allpaths.c:222
#10 0x000055d6c4272976 in query_planner (root=root@entry=0x55d6c5e9b250,
qp_callback=qp_callback@entry=0x55d6c42768fe <standard_qp_callback>,
qp_extra=qp_extra@entry=0x7ffcc2b6d5a0)
at planmain.c:269
#11 0x000055d6c4279aa4 in grouping_planner (root=root@entry=0x55d6c5e9b250,
inheritance_update=inheritance_update@entry=false,
tuple_fraction=<optimized out>, tuple_fraction@entry=0)
at planner.c:2058
#12 0x000055d6c427c041 in subquery_planner (glob=glob@entry=0x55d6c5e8b648,
parse=parse@entry=0x55d6c5d97ad8,
parent_root=parent_root@entry=0x0,
hasRecursion=hasRecursion@entry=false,
tuple_fraction=tuple_fraction@entry=0)
at planner.c:1015
#13 0x000055d6c427c6d7 in standard_planner (parse=0x55d6c5d97ad8,
query_string=<optimized out>, cursorOptions=256,
boundParams=<optimized out>) at planner.c:405
#14 0x000055d6c427cccb in planner (parse=parse@entry=0x55d6c5d97ad8,
query_string=query_string@entry=0x55d6c5d743d0 "EXPLAIN\nSELECT t1.c1,
t2.c1 FROM ft1 t1 JOIN ft1 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1;",
cursorOptions=cursorOptions@entry=256, boundParams=boundParams@entry=0x0) at
planner.c:275
#15 0x000055d6c435685d in pg_plan_query
(querytree=querytree@entry=0x55d6c5d97ad8,
query_string=query_string@entry=0x55d6c5d743d0 "EXPLAIN\nSELECT t1.c1,
t2.c1 FROM ft1 t1 JOIN ft1 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1;",
cursorOptions=cursorOptions@entry=256, boundParams=boundParams@entry=0x0)
at postgres.c:875
#16 0x000055d6c4145ed5 in ExplainOneQuery (query=0x55d6c5d97ad8,
cursorOptions=cursorOptions@entry=256,
into=into@entry=0x0, es=es@entry=0x55d6c5e681b0,
queryString=0x55d6c5d743d0 "EXPLAIN\nSELECT t1.c1, t2.c1 FROM ft1 t1
JOIN ft1 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1;",
params=params@entry=0x0, queryEnv=0x0) at explain.c:391
#17 0x000055d6c41468d1 in ExplainQuery (pstate=pstate@entry=0x55d6c5e59f70,
stmt=stmt@entry=0x55d6c5d75b38,
params=params@entry=0x0, dest=dest@entry=0x55d6c5e59ed8) at
../../../src/include/nodes/nodes.h:594
#18 0x000055d6c435c84b in standard_ProcessUtility (pstmt=0x55d6c5d75be0,
queryString=0x55d6c5d743d0 "EXPLAIN\nSELECT t1.c1, t2.c1 FROM ft1 t1
JOIN ft1 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1;",
context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0,
dest=0x55d6c5e59ed8, qc=0x7ffcc2b6da30)
at utility.c:829
#19 0x000055d6c435cdea in ProcessUtility (pstmt=pstmt@entry=0x55d6c5d75be0,
queryString=<optimized out>,
context=context@entry=PROCESS_UTILITY_TOPLEVEL, params=<optimized out>,
queryEnv=<optimized out>,
dest=dest@entry=0x55d6c5e59ed8, qc=0x7ffcc2b6da30) at utility.c:524
#20 0x000055d6c4359255 in PortalRunUtility
(portal=portal@entry=0x55d6c5dd7870, pstmt=0x55d6c5d75be0,
isTopLevel=<optimized out>, setHoldSnapshot=setHoldSnapshot@entry=true,
dest=dest@entry=0x55d6c5e59ed8,
qc=qc@entry=0x7ffcc2b6da30) at pquery.c:1157
#21 0x000055d6c435a069 in FillPortalStore
(portal=portal@entry=0x55d6c5dd7870, isTopLevel=isTopLevel@entry=true)
at ../../../src/include/nodes/nodes.h:594
#22 0x000055d6c435ac0f in PortalRun (portal=portal@entry=0x55d6c5dd7870,
count=count@entry=9223372036854775807,
isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true,
dest=dest@entry=0x55d6c5e71c50,
altdest=altdest@entry=0x55d6c5e71c50, qc=0x7ffcc2b6dc20) at
pquery.c:751
#23 0x000055d6c4356ed5 in exec_simple_query (
query_string=query_string@entry=0x55d6c5d743d0 "EXPLAIN\nSELECT t1.c1,
t2.c1 FROM ft1 t1 JOIN ft1 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1;") at
postgres.c:1239
#24 0x000055d6c4358df1 in PostgresMain (argc=<optimized out>,
argv=argv@entry=0x55d6c5d9fb18, dbname=<optimized out>,
username=<optimized out>) at postgres.c:4315
#25 0x000055d6c42c4726 in BackendRun (port=port@entry=0x55d6c5d98400) at
postmaster.c:4526
#26 0x000055d6c42c7881 in BackendStartup (port=port@entry=0x55d6c5d98400) at
postmaster.c:4210
#27 0x000055d6c42c7ac8 in ServerLoop () at postmaster.c:1739
#28 0x000055d6c42c8ff1 in PostmasterMain (argc=8, argv=<optimized out>) at
postmaster.c:1412
#29 0x000055d6c4212224 in main (argc=8, argv=0x55d6c5d6ea40) at main.c:210
This can be reproduced also by `make check -C contrib/postgres_fdw` with the
following change in contrib/postgres_fdw/sql/postgres_fdw.sql:
-DELETE FROM "S 1"."T 4" WHERE c1 % 3 != 0; -- delete for outer join
tests
+DELETE FROM "S 1"."T 4"; -- delete for outer join tests
The first bad commit is 08d2d58a.
Without the Assert() that query executes successfully.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #16807: Assert failed in postgres_fdw/estimate_path_cost_size with an empty foreign table
@ 2021-01-06 03:15 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 6+ messages in thread
From: Etsuro Fujita @ 2021-01-06 03:15 UTC (permalink / raw)
To: exclusion@gmail.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Wed, Jan 6, 2021 at 3:29 AM PG Bug reporting form
<noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 16807
> Logged by: Alexander Lakhin
> Email address: exclusion@gmail.com
> PostgreSQL version: 13.1
> Operating system: Ubuntu 20.04
> Description:
>
> When executing the following query:
> CREATE EXTENSION postgres_fdw;
>
> DO $d$
> BEGIN
> EXECUTE $$CREATE SERVER loopback FOREIGN DATA WRAPPER postgres_fdw
> OPTIONS (dbname '$$||current_database()||$$',
> port '$$||current_setting('port')||$$'
> )$$;
> END;
> $d$;
>
> CREATE USER MAPPING FOR CURRENT_USER SERVER loopback;
> CREATE TABLE t1 (c1 int NOT NULL);
> CREATE FOREIGN TABLE ft1 (c1 int NOT NULL) SERVER loopback OPTIONS
> (schema_name 'public', table_name 't1');
>
> INSERT INTO t1 SELECT id FROM generate_series(1, 100) id;
> DELETE FROM t1;
>
> ANALYZE ft1;
>
> EXPLAIN
> SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft1 t2 ON (t1.c1 = t2.c1) ORDER BY
> t1.c1, t2.c1;
>
> The assert-enabled server crashes with the stacktrace:
Reproduced. Will look into this closely.
Thanks for the report, Alexander!
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #16807: Assert failed in postgres_fdw/estimate_path_cost_size with an empty foreign table
@ 2021-01-14 02:56 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Etsuro Fujita @ 2021-01-14 02:56 UTC (permalink / raw)
To: exclusion@gmail.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Wed, Jan 6, 2021 at 12:15 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> Reproduced. Will look into this closely.
If foreignrel->tuples is set to zero, the retrieved_rows estimate will
also be set to zero, so the assertion pointed out upthread is not
correct. I think I mistakenly assumed that foreignrel->tuples would
have been forced to be at least one row, like foreignrel->rows, before
we get to estimate_path_cost_size(), which is not correct.
To fix, I think it would be better to adjust the assertion accordingly
than removing it, since it was added to make sure that the
retrieved_rows estimate is set to a sensible value. Attached is a
patch for that. I added a simpler test case as well.
Best regards,
Etsuro Fujita
Attachments:
fix-postgres_fdw-assertion.patch (application/octet-stream, 3.1K) download
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected/postgres_fdw.out
index c11092f8cc..d244421b46 100644
--- a/contrib/postgres_fdw/expected/postgres_fdw.out
+++ b/contrib/postgres_fdw/expected/postgres_fdw.out
@@ -602,6 +602,24 @@ SELECT t1."C 1", t2.c1, t3.c1 FROM "S 1"."T 1" t1 full join ft1 t2 full join ft2
RESET enable_hashjoin;
RESET enable_nestloop;
+-- Test executing assertion in estimate_path_cost_size() that makes sure that
+-- retrieved_rows estimate reused for costing pre-sorted foreign paths is set
+-- to a sensible value when the underlying foreign relation has tuples=0
+CREATE TABLE loct_empty (c1 int NOT NULL, c2 text);
+CREATE FOREIGN TABLE ft_empty (c1 int NOT NULL, c2 text)
+ SERVER loopback OPTIONS (table_name 'loct_empty');
+INSERT INTO loct_empty
+ SELECT id, 'AAA' || to_char(id, 'FM000') FROM generate_series(1, 100) id;
+DELETE FROM loct_empty;
+ANALYZE ft_empty;
+EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft_empty ORDER BY c1;
+ QUERY PLAN
+-------------------------------------------------------------------------------
+ Foreign Scan on public.ft_empty
+ Output: c1, c2
+ Remote SQL: SELECT c1, c2 FROM public.loct_empty ORDER BY c1 ASC NULLS LAST
+(3 rows)
+
-- ===================================================================
-- WHERE with remotely-executable conditions
-- ===================================================================
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index 2f2d4d171c..5c000e276b 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -2809,7 +2809,7 @@ estimate_path_cost_size(PlannerInfo *root,
*/
if (fpinfo->rel_startup_cost >= 0 && fpinfo->rel_total_cost >= 0)
{
- Assert(fpinfo->retrieved_rows >= 1);
+ Assert(fpinfo->retrieved_rows >= 0);
rows = fpinfo->rows;
retrieved_rows = fpinfo->retrieved_rows;
diff --git a/contrib/postgres_fdw/sql/postgres_fdw.sql b/contrib/postgres_fdw/sql/postgres_fdw.sql
index 25dbc08b98..a0329cd16b 100644
--- a/contrib/postgres_fdw/sql/postgres_fdw.sql
+++ b/contrib/postgres_fdw/sql/postgres_fdw.sql
@@ -298,6 +298,18 @@ SELECT t1."C 1", t2.c1, t3.c1 FROM "S 1"."T 1" t1 full join ft1 t2 full join ft2
RESET enable_hashjoin;
RESET enable_nestloop;
+-- Test executing assertion in estimate_path_cost_size() that makes sure that
+-- retrieved_rows estimate reused for costing pre-sorted foreign paths is set
+-- to a sensible value when the underlying foreign relation has tuples=0
+CREATE TABLE loct_empty (c1 int NOT NULL, c2 text);
+CREATE FOREIGN TABLE ft_empty (c1 int NOT NULL, c2 text)
+ SERVER loopback OPTIONS (table_name 'loct_empty');
+INSERT INTO loct_empty
+ SELECT id, 'AAA' || to_char(id, 'FM000') FROM generate_series(1, 100) id;
+DELETE FROM loct_empty;
+ANALYZE ft_empty;
+EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft_empty ORDER BY c1;
+
-- ===================================================================
-- WHERE with remotely-executable conditions
-- ===================================================================
* Re: BUG #16807: Assert failed in postgres_fdw/estimate_path_cost_size with an empty foreign table
@ 2021-01-14 04:30 Kyotaro Horiguchi <horikyota.ntt@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Kyotaro Horiguchi @ 2021-01-14 04:30 UTC (permalink / raw)
To: etsuro.fujita@gmail.com; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
At Thu, 14 Jan 2021 11:56:08 +0900, Etsuro Fujita <etsuro.fujita@gmail.com> wrote in
> On Wed, Jan 6, 2021 at 12:15 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> > Reproduced. Will look into this closely.
>
> If foreignrel->tuples is set to zero, the retrieved_rows estimate will
> also be set to zero, so the assertion pointed out upthread is not
> correct. I think I mistakenly assumed that foreignrel->tuples would
> have been forced to be at least one row, like foreignrel->rows, before
> we get to estimate_path_cost_size(), which is not correct.
>
> To fix, I think it would be better to adjust the assertion accordingly
> than removing it, since it was added to make sure that the
> retrieved_rows estimate is set to a sensible value. Attached is a
> patch for that. I added a simpler test case as well.
FWIW I drew the same conclusion.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #16807: Assert failed in postgres_fdw/estimate_path_cost_size with an empty foreign table
@ 2021-02-04 09:56 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Etsuro Fujita @ 2021-02-04 09:56 UTC (permalink / raw)
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; +Cc: exclusion@gmail.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Thu, Jan 14, 2021 at 1:30 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> At Thu, 14 Jan 2021 11:56:08 +0900, Etsuro Fujita <etsuro.fujita@gmail.com> wrote in
> > If foreignrel->tuples is set to zero, the retrieved_rows estimate will
> > also be set to zero, so the assertion pointed out upthread is not
> > correct. I think I mistakenly assumed that foreignrel->tuples would
> > have been forced to be at least one row, like foreignrel->rows, before
> > we get to estimate_path_cost_size(), which is not correct.
> >
> > To fix, I think it would be better to adjust the assertion accordingly
> > than removing it, since it was added to make sure that the
> > retrieved_rows estimate is set to a sensible value. Attached is a
> > patch for that. I added a simpler test case as well.
>
> FWIW I drew the same conclusion.
Ok, thanks for reviewing!
I tweaked a regression test comment a little bit and added the commit
message. Attached is an updated patch. I’ll commit the patch.
Best regards,
Etsuro Fujita
Attachments:
0001-postgres_fdw-Fix-assertion-in-estimate_path_cost_siz.patch (application/octet-stream, 4.1K) download
From c10d3ac78867859d623a36cceed22f2ec2ff9b8c Mon Sep 17 00:00:00 2001
From: Etsuro Fujita <etsuro.fujita@gmail.com>
Date: Thu, 4 Feb 2021 18:48:37 +0900
Subject: [PATCH] postgres_fdw: Fix assertion in estimate_path_cost_size().
In commit 08d2d58a2, I assumed that the retrieved_rows estimate for a
foreign relation, which is re-used to cost pre-sorted foreign paths with
local stats, is set to at least one row in estimate_path_cost_size(),
which is not correct: when the relation is a foreign table with tuples=0,
the estimate would be set to 0 when not using remote estimates.
Back-patch to v13 where the aforementioned commit went in.
Per bug #16807 from Alexander Lakhin.
Author: Etsuro Fujita
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/16807-9fe4e08fbaa5c7ce%40postgresql.org
---
contrib/postgres_fdw/expected/postgres_fdw.out | 18 ++++++++++++++++++
contrib/postgres_fdw/postgres_fdw.c | 2 +-
contrib/postgres_fdw/sql/postgres_fdw.sql | 12 ++++++++++++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected/postgres_fdw.out
index b09dce63f5..60c7e115d6 100644
--- a/contrib/postgres_fdw/expected/postgres_fdw.out
+++ b/contrib/postgres_fdw/expected/postgres_fdw.out
@@ -613,6 +613,24 @@ SELECT t1."C 1", t2.c1, t3.c1 FROM "S 1"."T 1" t1 full join ft1 t2 full join ft2
RESET enable_hashjoin;
RESET enable_nestloop;
+-- Test executing assertion in estimate_path_cost_size() that makes sure that
+-- retrieved_rows for foreign rel re-used to cost pre-sorted foreign paths is
+-- a sensible value even when the rel has tuples=0
+CREATE TABLE loct_empty (c1 int NOT NULL, c2 text);
+CREATE FOREIGN TABLE ft_empty (c1 int NOT NULL, c2 text)
+ SERVER loopback OPTIONS (table_name 'loct_empty');
+INSERT INTO loct_empty
+ SELECT id, 'AAA' || to_char(id, 'FM000') FROM generate_series(1, 100) id;
+DELETE FROM loct_empty;
+ANALYZE ft_empty;
+EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft_empty ORDER BY c1;
+ QUERY PLAN
+-------------------------------------------------------------------------------
+ Foreign Scan on public.ft_empty
+ Output: c1, c2
+ Remote SQL: SELECT c1, c2 FROM public.loct_empty ORDER BY c1 ASC NULLS LAST
+(3 rows)
+
-- ===================================================================
-- WHERE with remotely-executable conditions
-- ===================================================================
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index 2ce42ce3f1..0e977066a8 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -2923,7 +2923,7 @@ estimate_path_cost_size(PlannerInfo *root,
*/
if (fpinfo->rel_startup_cost >= 0 && fpinfo->rel_total_cost >= 0)
{
- Assert(fpinfo->retrieved_rows >= 1);
+ Assert(fpinfo->retrieved_rows >= 0);
rows = fpinfo->rows;
retrieved_rows = fpinfo->retrieved_rows;
diff --git a/contrib/postgres_fdw/sql/postgres_fdw.sql b/contrib/postgres_fdw/sql/postgres_fdw.sql
index 319c15d635..151f4f1834 100644
--- a/contrib/postgres_fdw/sql/postgres_fdw.sql
+++ b/contrib/postgres_fdw/sql/postgres_fdw.sql
@@ -309,6 +309,18 @@ SELECT t1."C 1", t2.c1, t3.c1 FROM "S 1"."T 1" t1 full join ft1 t2 full join ft2
RESET enable_hashjoin;
RESET enable_nestloop;
+-- Test executing assertion in estimate_path_cost_size() that makes sure that
+-- retrieved_rows for foreign rel re-used to cost pre-sorted foreign paths is
+-- a sensible value even when the rel has tuples=0
+CREATE TABLE loct_empty (c1 int NOT NULL, c2 text);
+CREATE FOREIGN TABLE ft_empty (c1 int NOT NULL, c2 text)
+ SERVER loopback OPTIONS (table_name 'loct_empty');
+INSERT INTO loct_empty
+ SELECT id, 'AAA' || to_char(id, 'FM000') FROM generate_series(1, 100) id;
+DELETE FROM loct_empty;
+ANALYZE ft_empty;
+EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft_empty ORDER BY c1;
+
-- ===================================================================
-- WHERE with remotely-executable conditions
-- ===================================================================
--
2.14.3 (Apple Git-98)
* Re: BUG #16807: Assert failed in postgres_fdw/estimate_path_cost_size with an empty foreign table
@ 2021-02-05 06:38 Etsuro Fujita <etsuro.fujita@gmail.com>
parent: Etsuro Fujita <etsuro.fujita@gmail.com>
0 siblings, 0 replies; 6+ messages in thread
From: Etsuro Fujita @ 2021-02-05 06:38 UTC (permalink / raw)
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; +Cc: exclusion@gmail.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Thu, Feb 4, 2021 at 6:56 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> I tweaked a regression test comment a little bit and added the commit
> message. Attached is an updated patch. I’ll commit the patch.
Pushed.
Best regards,
Etsuro Fujita
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2021-02-05 06:38 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-01-05 18:00 BUG #16807: Assert failed in postgres_fdw/estimate_path_cost_size with an empty foreign table PG Bug reporting form <noreply@postgresql.org>
2021-01-06 03:15 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2021-01-14 02:56 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2021-01-14 04:30 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2021-02-04 09:56 ` Etsuro Fujita <etsuro.fujita@gmail.com>
2021-02-05 06:38 ` Etsuro Fujita <etsuro.fujita@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox