Chris Mair <chris@xxxxxxxx> writes: > Whenever a session has performed a query on a foreign table, any subsequent > query on a local table big enough to use the parallel query feature exits with > an error: > ERROR: invalid cache ID: 41 > CONTEXT: parallel worker Hm, syscache 41 is PROCNAMEARGSNSP in 9.6, if I counted right. > (gdb) bt > #0 0x00007f16a0f4d1f7 in raise () from /lib64/libc.so.6 > #1 0x00007f16a0f4e8e8 in abort () from /lib64/libc.so.6 > #2 0x00000000008094b4 in errfinish (dummy=dummy@entry=0) at elog.c:557 > #3 0x000000000080aea2 in elog_finish (elevel=elevel@entry=22, fmt=fmt@entry=0x9d9965 "invalid cache ID: %d") at elog.c:1378 > #4 0x00000000007ffd82 in SearchSysCacheList (cacheId=cacheId@entry=41, nkeys=nkeys@entry=2, key1=key1@entry=139734905138463, key2=<optimized out>, key3=key3@entry=0, key4=key4@entry=0) at syscache.c:1210 > #5 0x00007f169161a59f in _PG_init () at oracle_fdw.c:709 > #6 0x000000000080c476 in internal_load_library (libname=<optimized out>, libname@entry=0x7f16a1bfdde8 <Address 0x7f16a1bfdde8 out of bounds>) at dfmgr.c:276 > #7 0x000000000080c708 in RestoreLibraryState (start_address=0x7f16a1bfdde8 <Address 0x7f16a1bfdde8 out of bounds>) at dfmgr.c:741 > #8 0x00000000004e72cf in ParallelWorkerMain (main_arg=<optimized out>) at parallel.c:1069 Apparently, oracle_fdw is trying to do a procedure lookup in its _PG_init function. This is a horrible idea: it assumes that _PG_init is invoked inside a transaction, which is wrong if the library is preloaded, for example. (I'd bet that adding oracle_fdw to shared_preload_libraries would fail badly, though perhaps not with this exact error message.) So I'd call this an oracle_fdw bug. It needs to postpone what it's doing here to the first normal FDW function call in a session. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
