BUG #17344: Assert failed on queiring async_capable foreign table with inheritance

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: exclusion(at)gmail(dot)com
Subject: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance
Date: 2021-12-25 10:00:01
Message-ID: 17344-226b78b00de73a7e@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 17344
Logged by: Alexander Lakhin
Email address: exclusion(at)gmail(dot)com
PostgreSQL version: 14.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')||$$',
async_capable 'true'
)$$;
end;
$d$;
create user mapping for current_user server loopback;

create table tab1 (a int);
insert into tab1 values(1), (2), (3);
create foreign table ftab1 (b int) server loopback options (table_name
'tab1');

create foreign table ftab2 () inherits (ftab1) server loopback;
select a from tab1 where a in (select a from ftab1);

I get an assertion failed with the stacktrace:
Core was generated by `postgres: law regression [local] SELECT
'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig(at)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(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f2a2f9fa859 in __GI_abort () at abort.c:79
#2 0x0000557dece3c5d8 in ExceptionalCondition
(conditionName=conditionName(at)entry=0x7f2a225a8da7 "areq != pendingAreq",
errorType=errorType(at)entry=0x7f2a225a76aa "FailedAssertion",
fileName=0x7ffde2262540 "\271\305\343\354}U",
fileName(at)entry=0x7f2a225a88af "postgres_fdw.c",
lineNumber=lineNumber(at)entry=6974) at assert.c:69
#3 0x00007f2a225a4e34 in produce_tuple_asynchronously (areq=<optimized
out>, fetch=<optimized out>)
at postgres_fdw.c:6974
#4 0x0000557decb6e152 in ExecAsyncRequest (areq=0x557ded812670) at
execAsync.c:38
#5 0x0000557decb94e4e in ExecAppendAsyncBegin (node=0x557ded7f2040) at
nodeAppend.c:907
#6 ExecAppend (pstate=0x557ded7f2040) at nodeAppend.c:317
#7 0x0000557decbb0183 in ExecProcNode (node=0x557ded7f2040) at
../../../src/include/executor/executor.h:257
#8 ExecResult (pstate=0x557ded7f1e38) at nodeResult.c:115
#9 0x0000557decbb263d in ExecProcNode (node=0x557ded7f1e38) at
../../../src/include/executor/executor.h:257
#10 ExecScanSubPlan (isNull=0x557ded81ba35, econtext=0x557ded81b7e8,
node=0x557ded81c2e0) at nodeSubplan.c:323
#11 ExecSubPlan (node=node(at)entry=0x557ded81c2e0,
econtext=econtext(at)entry=0x557ded81b7e8, isNull=0x557ded81ba35)
at nodeSubplan.c:89
#12 0x0000557decb77beb in ExecEvalSubPlan (econtext=0x557ded81b7e8,
op=<optimized out>, state=0x557ded81ba30)
at execExprInterp.c:3932
#13 ExecInterpExpr (state=0x557ded81ba30, econtext=0x557ded81b7e8,
isnull=<optimized out>) at execExprInterp.c:1564
#14 0x0000557decb865d5 in ExecEvalExprSwitchContext (isNull=0x7ffde2262ad7,
econtext=0x557ded81b7e8,
state=0x557ded81ba30) at ../../../src/include/executor/executor.h:339
#15 ExecQual (econtext=0x557ded81b7e8, state=0x557ded81ba30) at
../../../src/include/executor/executor.h:408
#16 ExecScan (node=0x557ded7f3748, accessMtd=0x557decbb0ad0 <SeqNext>,
recheckMtd=0x557decbb0ac0 <SeqRecheck>)
at execScan.c:227
#17 0x0000557decb7cc7a in ExecProcNode (node=0x557ded7f3748) at
../../../src/include/executor/executor.h:257
#18 ExecutePlan (execute_once=<optimized out>, dest=0x557ded80a428,
direction=<optimized out>, numberTuples=0,
sendTuples=<optimized out>, operation=CMD_SELECT,
use_parallel_mode=<optimized out>, planstate=0x557ded7f3748,
estate=0x557ded7f1b90) at execMain.c:1551
#19 standard_ExecutorRun (queryDesc=0x557ded800c20, direction=<optimized
out>, count=0, execute_once=<optimized out>)
at execMain.c:361
#20 0x0000557decd18b9c in PortalRunSelect (portal=0x557ded756860,
forward=<optimized out>, count=0,
dest=<optimized out>) at pquery.c:921
#21 0x0000557decd1a2cb in PortalRun (portal=portal(at)entry=0x557ded756860,
count=count(at)entry=9223372036854775807,
isTopLevel=isTopLevel(at)entry=true, run_once=run_once(at)entry=true,
dest=dest(at)entry=0x557ded80a428,
altdest=altdest(at)entry=0x557ded80a428, qc=0x7ffde2262d80) at
pquery.c:765
#22 0x0000557decd1614b in exec_simple_query (
query_string=0x557ded6e7960 "select a from tab1 where a in (select a
from ftab1);") at postgres.c:1214
#23 0x0000557decd17d51 in PostgresMain (argc=argc(at)entry=1,
argv=argv(at)entry=0x7ffde22631f0, dbname=<optimized out>,
username=<optimized out>) at postgres.c:4486
#24 0x0000557decc83c8d in BackendRun (port=0x557ded70b3d0,
port=0x557ded70b3d0) at postmaster.c:4530
#25 BackendStartup (port=0x557ded70b3d0) at postmaster.c:4252
#26 ServerLoop () at postmaster.c:1745
#27 0x0000557decc84c31 in PostmasterMain (argc=<optimized out>,
argv=<optimized out>) at postmaster.c:1417
#28 0x0000557dec9b24b2 in main (argc=3, argv=0x557ded6e1990) at main.c:209

With async_capable = 'false' I get expected results.
But when ftab1 defined as
create foreign table ftab1 (a int) server loopback options (table_name
'tab1');
The select fails with:
psql:query.sql:19: ERROR: could not connect to server "loopback"
DETAIL: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL:
sorry, too many clients already
CONTEXT: remote SQL command: SELECT a FROM public.ftab2
remote SQL command: SELECT a FROM public.ftab2
remote SQL command: SELECT a FROM public.ftab2
remote SQL command: SELECT a FROM public.ftab2
...
with or without async_capable.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dmitry Dolgov 2021-12-25 23:26:25 Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance
Previous Message David G. Johnston 2021-12-25 00:09:48 Re: BUG #17343: ! at end of password for psql throws error