Hi, 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/nodeFunctionscan.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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
