BUG #17344: Assert failed on queiring async_capable foreign table with inheritance - Mailing list pgsql-bugs
From | PG Bug reporting form |
---|---|
Subject | BUG #17344: Assert failed on queiring async_capable foreign table with inheritance |
Date | |
Msg-id | 17344-226b78b00de73a7e@postgresql.org Whole thread Raw |
Responses |
Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance
|
List | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 17344 Logged by: Alexander Lakhin Email address: exclusion@gmail.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@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 0x00007f2a2f9fa859 in __GI_abort () at abort.c:79 #2 0x0000557dece3c5d8 in ExceptionalCondition (conditionName=conditionName@entry=0x7f2a225a8da7 "areq != pendingAreq", errorType=errorType@entry=0x7f2a225a76aa "FailedAssertion", fileName=0x7ffde2262540 "\271\305\343\354}U", fileName@entry=0x7f2a225a88af "postgres_fdw.c", lineNumber=lineNumber@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@entry=0x557ded81c2e0, econtext=econtext@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@entry=0x557ded756860, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=dest@entry=0x557ded80a428, altdest=altdest@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@entry=1, argv=argv@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.
pgsql-bugs by date: