Join between distributed table and catalog table-information_schemas erroring out weirdly

[saicitus]

Steps for reproducing the issues:

create table test_dist (id int, table_name text, column_name text);
select create_distributed_table('test_dist','id');
select * from test_dist td join information_schema.columns icl on  icl.table_name::text = lower(td.table_name) and icl.column_name::text=lower(td.column_name);
ERROR:  could not open relation with OID 0

ERROR: could not open relation with OID 0 seems weird. We could just error out saying that we cannot join distributed and local tables. Could it be that Citus planner/executor is getting confused because information_schemas is also on the workers. Not sure however.

[marcocitus]

Stack trace for the error:

(gdb) bt
#0  errstart (elevel=elevel@entry=20, filename=0x8794d1 "heapam.c", lineno=1138, funcname=0x879e72 <__func__.20340> "relation_open", domain=domain@entry=0x0) at elog.c:251
#1  0x0000000000836679 in elog_finish (elevel=elevel@entry=20, fmt=fmt@entry=0x8797e8 "could not open relation with OID %u") at elog.c:1358
#2  0x00000000004b116a in relation_open (relationId=relationId@entry=0, lockmode=lockmode@entry=1) at heapam.c:1138
#3  0x00000000004b130e in heap_open (relationId=relationId@entry=0, lockmode=lockmode@entry=1) at heapam.c:1298
#4  0x00007f5fba9b4b06 in PartitionedTable (relationId=relationId@entry=0) at utils/multi_partitioning_utils.c:43
#5  0x00007f5fba9b845e in LockPartitionsInRelationList (relationIdList=<optimized out>, lockmode=lockmode@entry=1) at utils/resource_lock.c:628
#6  0x00007f5fba9715e7 in LockPartitionsForDistributedPlan (distributedPlan=distributedPlan@entry=0x7f5fab1225a0) at executor/adaptive_executor.c:1023
#7  0x00007f5fba973681 in AdaptiveExecutor (node=node@entry=0x16e3bc0) at executor/adaptive_executor.c:600
#8  0x00007f5fba973b42 in CitusExecScan (node=0x16e3bc0) at executor/citus_custom_scan.c:191
#9  0x000000000060c1c5 in ExecCustomScan (pstate=0x16e3bc0) at nodeCustom.c:114
#10 0x00000000005ff0b0 in ExecProcNodeFirst (node=0x16e3bc0) at execProcnode.c:445
#11 0x00000000005f8707 in ExecProcNode (node=0x16e3bc0) at ../../../src/include/executor/executor.h:247
#12 ExecutePlan (estate=estate@entry=0x16e3960, planstate=0x16e3bc0, use_parallel_mode=false, operation=operation@entry=CMD_SELECT, sendTuples=sendTuples@entry=true, 
    numberTuples=numberTuples@entry=0, direction=direction@entry=ForwardScanDirection, dest=dest@entry=0x7f5fab1277f8, execute_once=execute_once@entry=true) at execMain.c:1723
#13 0x00000000005f922f in standard_ExecutorRun (queryDesc=queryDesc@entry=0x16cdb60, direction=direction@entry=ForwardScanDirection, count=count@entry=0, 
    execute_once=execute_once@entry=true) at execMain.c:364
#14 0x00007f5fba975eb5 in CitusExecutorRun (queryDesc=0x16cdb60, direction=ForwardScanDirection, count=0, execute_once=<optimized out>) at executor/multi_executor.c:149
#15 0x00007f5fb7f32515 in pgss_ExecutorRun (queryDesc=0x16cdb60, direction=ForwardScanDirection, count=0, execute_once=<optimized out>) at pg_stat_statements.c:890
#16 0x00000000005f92a1 in ExecutorRun (queryDesc=queryDesc@entry=0x16cdb60, direction=direction@entry=ForwardScanDirection, count=count@entry=0, execute_once=<optimized out>)
    at execMain.c:305
#17 0x0000000000735338 in PortalRunSelect (portal=portal@entry=0x15f42a0, forward=forward@entry=true, count=0, count@entry=9223372036854775807, dest=dest@entry=0x7f5fab1277f8)
    at pquery.c:932
#18 0x0000000000736734 in PortalRun (portal=portal@entry=0x15f42a0, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, 
    dest=dest@entry=0x7f5fab1277f8, altdest=altdest@entry=0x7f5fab1277f8, completionTag=completionTag@entry=0x7ffd27d1b430 "") at pquery.c:773
#19 0x0000000000733139 in exec_simple_query (
    query_string=query_string@entry=0x1535f60 "select * from test_dist td join information_schema.columns icl on  icl.table_name::text = lower(td.table_name) and icl.column_name::text=lower(td.column_name);") at postgres.c:1145
#20 0x0000000000734cc4 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x15a5d60, dbname=0x15a5c40 "postgres", username=<optimized out>) at postgres.c:4182
#21 0x00000000006c8428 in BackendRun (port=port@entry=0x1551d80) at postmaster.c:4358
#22 0x00000000006cacb0 in BackendStartup (port=port@entry=0x1551d80) at postmaster.c:4030
#23 0x00000000006caf59 in ServerLoop () at postmaster.c:1707
#24 0x00000000006cc133 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x1530b80) at postmaster.c:1380
#25 0x000000000063eb28 in main (argc=3, argv=0x1530b80) at main.c:228

Interestingly, we get all the way to the executor, but then fail on opening the relation. The reason we manage to plan this query is that information_schema.columns is a view which gets converted into a subquery. Subqueries containing only local tables are handled by recursive planning.

We may actually be able to make this query work if we add a check in PartitionedTable.