|
On 11/15/2012 08:40 PM, Cédric Villemain wrote: > top post: this looks like a plproxy bug (no ?), I've added Marko in CC. Yes, it is, i think … > > >> I've a segfault on a PostgreSQL 9.1 cluster, with a plproxy function >> call. Both PostgreSQL and plproxy are up to date. I use SQL/MED in that >> specific case, but it's the same without. I reproduced the following >> scenario on a few clusters, with or without streaming replication. >> >> On a given cluster, I created this function (very stupid, I know) (note >> the « returns table () » ) : >> >> p0=# create function testtoto( id int) >> returns table(id int, t text) >> language sql >> as $$ >> select * from (values(1, 'test'),(2, 'toto') )as toto; >> $$; >> p0=# \df testtoto >> List of functions >> Schema | Name | Result data type | Argument data types | Type >> --------+----------+---------------------------+---------------------+----- >> --- public | testtoto | TABLE(id integer, t text) | id integer | normal (1 >> row) >> >> >> And I use it on another cluster, by doing this : >> >> test=# CREATE SERVER test FOREIGN DATA WRAPPER plproxy >> options( connection_lifetime '200',p0 'host=localhost port=5433 >> dbname=p0 user=postgres'); >> CREATE USER MAPPING FOR postgres SERVER test OPTIONS (user 'postgres'); >> >> -- this function returns setof record >> >> test=# CREATE OR REPLACE FUNCTION test(IN _account_id integer, OUT id >> integer, OUT t text ) >> RETURNS setof record >> LANGUAGE plproxy >> AS $function$ >> CLUSTER 'test'; >> TARGET testtoto; >> $function$; >> >> -- this on returns TABLE() >> >> test=# CREATE OR REPLACE FUNCTION test2(IN _account_id integer) >> returns TABLE( id integer, t text ) >> LANGUAGE plproxyAS $function$ >> CLUSTER 'test'; >> TARGET testtoto; >> $function$; >> >> When I call test(), everything is OK : >> >> test=# select * from test(1); >> id | t >> ----+------ >> 1 | test >> 2 | toto >> (2 rows) >> >> But when I call test2(1) : >> >> test=# select pg_backend_pid(); >> pg_backend_pid >> ---------------- >> 25330 >> (1 row) >> test=# select * from test2(1); >> The connection to the server was lost. Attempting reset: Failed. >> !> >> >> Badaboum ! >> >> And the log reads : >> >> 2012-11-15 18:07:55 CET LOG: server process (PID 25330) was terminated >> by signal 11: Segmentation fault >> 2012-11-15 18:07:55 CET LOG: terminating any other active server processes >> 2012-11-15 18:07:55 CET WARNING: terminating connection because of crash >> of another server process >> 2012-11-15 18:07:55 CET DETAIL: The postmaster has commanded this server >> process to roll back the current transaction and exit, because another >> server process exited abnormally and possibly corrupted shared memory. >> 2012-11-15 18:07:55 CET HINT: In a moment you should be able to >> reconnect to the database and repeat your command. >> >> … >> >> When I try to debug the session, I get this trace : >> >> (gdb) >> Run till exit from #0 PostgresMain (argc=<optimized out>, >> argv=<optimized out>, username=<optimized out>) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/tcop/postgres.c:3932 >> >> Program received signal SIGSEGV, Segmentation fault. >> pg_detoast_datum_packed (datum=0x800000000) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:2272 >> 2272 if (VARATT_IS_COMPRESSED(datum) || VARATT_IS_EXTERNAL(datum)) >> (gdb) bt >> #0 pg_detoast_datum_packed (datum=0x800000000) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:2272 >> #1 0x00007f26ea7c0040 in text_to_cstring (t=0x800000000) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/adt/varlena.c:135 >> #2 0x00007f26ea80a8c6 in FunctionCall1Coll (flinfo=0x7f26eb7fa2b8, >> collation=0, arg1=34359738368) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:1300 >> #3 0x00007f26ea80ba2d in OutputFunctionCall (flinfo=0x7f26eb7fa2b8, >> val=34359738368) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:1953 >> #4 0x00007f26611c2577 in plproxy_send_type () from >> /usr/lib/postgresql/9.1/lib/plproxy.so >> #5 0x00007f26611bfe66 in plproxy_exec () from >> /usr/lib/postgresql/9.1/lib/plproxy.so >> #6 0x00007f26611c1634 in ?? () from /usr/lib/postgresql/9.1/lib/plproxy.so >> #7 0x00007f26611c1865 in plproxy_call_handler () from >> /usr/lib/postgresql/9.1/lib/plproxy.so >> #8 0x00007f26ea677985 in ExecMakeTableFunctionResult >> (funcexpr=0x7f26eb7e9020, econtext=0x7f26eb7e7ff0, >> expectedDesc=<optimized out>, randomAccess=<optimized out>) >> at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execQual.c:2146 >> #9 0x00007f26ea688471 in FunctionNext (node=0x7f26eb7e7ee0) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/nodeFunctionsca >> n.c:66 #10 0x00007f26ea678657 in ExecScanFetch (recheckMtd=<optimized out>, >> accessMtd=<optimized out>, node=<optimized out>) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execScan.c:82 >> #11 ExecScan (node=0x7f26eb7e7ee0, accessMtd=<optimized out>, >> recheckMtd=<optimized out>) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execScan.c:132 >> #12 0x00007f26ea670da8 in ExecProcNode (node=0x7f26eb7e7ee0) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execProcnode.c: >> 416 #13 0x00007f26ea66fbf2 in ExecutePlan (dest=<optimized out>, >> direction=<optimized out>, numberTuples=<optimized out>, >> sendTuples=<optimized out>, operation=<optimized out>, >> planstate=<optimized out>, estate=<optimized out>) >> at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execMain.c:1440 >> #14 standard_ExecutorRun (queryDesc=0x7f26eb7a1790, >> direction=NoMovementScanDirection, count=0) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execMain.c:314 >> #15 0x00007f26ea7461d7 in PortalRunSelect (portal=0x7f26eb7dbd90, >> forward=<optimized out>, count=0, dest=0x7f26eb6d87a0) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/tcop/pquery.c:943 >> #16 0x00007f26ea747640 in PortalRun (portal=<optimized out>, >> count=<optimized out>, isTopLevel=<optimized out>, dest=<optimized out>, >> altdest=<optimized out>, completionTag=<optimized out>) >> at /opt/src/postgresql-9.1-9.1.6/build/../src/backend/tcop/pquery.c:787 >> #17 0x00007f26ea7438a3 in exec_simple_query (query_string=<optimized >> out>) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/tcop/postgres.c:1020 >> #18 0x00007f26ea744965 in PostgresMain (argc=<optimized out>, >> argv=<optimized out>, username=<optimized out>) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/tcop/postgres.c:3968 >> #19 0x00007f26ea702da3 in BackendRun (port=<optimized out>) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/postmaster/postmaster.c: >> 3617 #20 BackendStartup (port=<optimized out>) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/postmaster/postmaster.c: >> 3302 #21 ServerLoop () at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/postmaster/postmaster.c: >> 1466 #22 0x00007f26ea705861 in PostmasterMain (argc=-345045536, >> argv=0x7f26eb6cb200) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/postmaster/postmaster.c: >> 1127 #23 0x00007f26ea6a3dc3 in main (argc=5, argv=0x7f26eb6cb1e0) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/main/main.c:199 >> (gdb) quit >> >> >> We can see here that "return setof record" works fine, but "return >> table()" crashes. >> >> Even if we can use the first syntax, I don't think we can accept that. > -- Sébastien Lardière PostgreSQL DBA Team Manager Hi-Media 0228082071 / 0626595833 |
