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

> On Sat, Dec 25, 2021 at 10:00:01AM +0000, PG Bug reporting form wrote:
>
> 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);
>
> 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

Apparently in both cases the second foreign scan of append ends up in
recursion:

-> Foreign Scan on public.ftab2 ftab1_2
Remote SQL: SELECT NULL FROM public.ftab2

This leads to a chain of the same cursor declarations:

DECLARE c1 CURSOR FOR SELECT a FROM public.ftab4

With a pattern:

bind -> new backend with the same declare -> execute -> bind -> ...

In the case of async foreign scan it hits limitation when no new
requests be sent while there is a pending one. In the second case it
hits connection limit. Shouldn't this type of foreign paths be avoided
by FDW?