Thread: [BUGS] BUG #14522: plpythonu, missed filenode

[BUGS] BUG #14522: plpythonu, missed filenode

From
pasquini.matteo@gmail.com
Date:
The following bug has been logged on the website:

Bug reference:      14522
Logged by:          Matteo Pasquini
Email address:      pasquini.matteo@gmail.com
PostgreSQL version: 9.6.1
Operating system:   linux x64, debian8
Description:

got: [...] "base/23417/2659":no such file or directory
sqlcode : 58P01
while using plpython functions, usually after 2nd call of a plpython
function.

I've this big python app that cannot be translated entirely in plpython, so
i've managed to 
- give to postgres execution of python app (/var/lib/postgresql/pyapp)
- with plpythonu add the path of the app to be able to make import in all
pther functions.

$$
from sys import path
pyapp = '/var/lib/postgresql/pyapp'
if not pyapp in path:
    path.append(pyapp)
    path = set(path)
$$

- Then, call another plpython function that produce data. 
that function convert a file from filesystem and give back a list of values,
it works as expected.


The file "base/23417/2659" is there
-rw------ 1 postgres postgres 80K Feb 1 17:25 base/23417/2659

and both 

select * from pg_dabase where oid = 23417;
select * from pg_class where relfilenode = 2659;

returns as expected.

haven't find similar issues around for version 9.6.x

After some tries the error becomes permanent.


Thanks.






--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #14522: plpythonu, missed filenode

From
Tom Lane
Date:
pasquini.matteo@gmail.com writes:
> got: [...] "base/23417/2659":no such file or directory
> sqlcode : 58P01
> while using plpython functions, usually after 2nd call of a plpython
> function.

You're not really going to get any responses to this if you don't provide
a self-contained, reproducible test case.  It may well be a "so don't do
that" case anyway --- running arbitrary Python code inside a PG backend
strikes me as a seriously dangerous thing to do, especially given Python's
lack of any safe sandbox mode.  (An example is that allowing the backend
process to become multithreaded would almost certainly break things.)
But without knowing what your Python code is doing, there's no way to
investigate.

            regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs