Chris Mair <chris@1006.org> 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
0x7f16a1bfdde8out of bounds>) at dfmgr.c:276
> #7 0x000000000080c708 in RestoreLibraryState (start_address=0x7f16a1bfdde8 <Address 0x7f16a1bfdde8 out of bounds>)
atdfmgr.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
