Re: [GENERAL] Plproxy with returns table() make PG segfault
On Fri, Nov 16, 2012 at 11:09 AM, Sébastien Lardière wrote: > 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 … Thanks, fixed in git. Fix will be in 2.5 release. -- marko -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Plproxy with returns table() make PG segfault
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=, >> argv=, username=) 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=0x8) 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=0x8) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:2272 >> #1 0x7f26ea7c0040 in text_to_cstring (t=0x8) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/adt/varlena.c:135 >> #2 0x7f26ea80a8c6 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 0x7f26ea80ba2d in OutputFunctionCall (flinfo=0x7f26eb7fa2b8, >> val=34359738368) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:1953 >> #4 0x7f26611c2577 in plproxy_send_type () from >> /usr/lib/postgresql/9.1/lib/plproxy.so >> #5 0x7f26611bfe66 in plproxy_exec () from >> /usr/lib/postgresql/9.1/lib/plproxy.so >> #6 0x7f26611c1634 in ?? () from /usr/lib/postgresql/9.1/lib/plproxy.so >> #7 0x7f26611c1865 in plproxy_call_handler () from >> /usr/lib/postgresql/9.1/lib/plproxy.so >> #8 0x7f26ea677985 in ExecMakeTableFunctionResult >> (funcexpr=0x7f26eb7e9020, econtext=0x7f26eb7e7ff0, >> expectedDesc=, randomAccess=) >> at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execQual.c:2146 >> #9 0x7f26ea688471 in FunctionNext (node=0x7f26eb7e7ee0) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/nodeFunctionsca >> n.c:66 #10 0x7f26ea678657 in ExecScanFetch (recheckMtd=, >> accessMtd=, node=) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execScan.c:82 >> #11 ExecScan (node=0x7f26eb7e7ee0, accessMtd=, >> recheckMtd=) at >> /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execScan.c:132
Re: [GENERAL] Plproxy with returns table() make PG segfault
top post: this looks like a plproxy bug (no ?), I've added Marko in CC. > 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=, > argv=, username=) 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=0x8) 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=0x8) at > /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:2272 > #1 0x7f26ea7c0040 in text_to_cstring (t=0x8) at > /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/adt/varlena.c:135 > #2 0x7f26ea80a8c6 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 0x7f26ea80ba2d in OutputFunctionCall (flinfo=0x7f26eb7fa2b8, > val=34359738368) at > /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:1953 > #4 0x7f26611c2577 in plproxy_send_type () from > /usr/lib/postgresql/9.1/lib/plproxy.so > #5 0x7f26611bfe66 in plproxy_exec () from > /usr/lib/postgresql/9.1/lib/plproxy.so > #6 0x7f26611c1634 in ?? () from /usr/lib/postgresql/9.1/lib/plproxy.so > #7 0x7f26611c1865 in plproxy_call_handler () from > /usr/lib/postgresql/9.1/lib/plproxy.so > #8 0x7f26ea677985 in ExecMakeTableFunctionResult > (funcexpr=0x7f26eb7e9020, econtext=0x7f26eb7e7ff0, > expectedDesc=, randomAccess=) > at > /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execQual.c:2146 > #9 0x7f26ea688471 in FunctionNext (node=0x7f26eb7e7ee0) at > /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/nodeFunctionsca > n.c:66 #10 0x7f26ea678657 in ExecScanFetch (recheckMtd=, > accessMtd=, node=) at > /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execScan.c:82 > #11 ExecScan (node=0x7f26eb7e7ee0, accessMtd=, > recheckMtd=) at > /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execScan.c:132 > #12 0x7f26ea670da8 in ExecProcNode (node=0x7f26eb7e7ee0) at > /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execProcnode.c: > 416 #13 0x7f26ea66fbf2 in ExecutePl
[GENERAL] Plproxy with returns table() make PG segfault
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=, argv=, username=) 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=0x8) 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=0x8) at /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:2272 #1 0x7f26ea7c0040 in text_to_cstring (t=0x8) at /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/adt/varlena.c:135 #2 0x7f26ea80a8c6 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 0x7f26ea80ba2d in OutputFunctionCall (flinfo=0x7f26eb7fa2b8, val=34359738368) at /opt/src/postgresql-9.1-9.1.6/build/../src/backend/utils/fmgr/fmgr.c:1953 #4 0x7f26611c2577 in plproxy_send_type () from /usr/lib/postgresql/9.1/lib/plproxy.so #5 0x7f26611bfe66 in plproxy_exec () from /usr/lib/postgresql/9.1/lib/plproxy.so #6 0x7f26611c1634 in ?? () from /usr/lib/postgresql/9.1/lib/plproxy.so #7 0x7f26611c1865 in plproxy_call_handler () from /usr/lib/postgresql/9.1/lib/plproxy.so #8 0x7f26ea677985 in ExecMakeTableFunctionResult (funcexpr=0x7f26eb7e9020, econtext=0x7f26eb7e7ff0, expectedDesc=, randomAccess=) at /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execQual.c:2146 #9 0x7f26ea688471 in FunctionNext (node=0x7f26eb7e7ee0) at /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/nodeFunctionscan.c:66 #10 0x7f26ea678657 in ExecScanFetch (recheckMtd=, accessMtd=, node=) at /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execScan.c:82 #11 ExecScan (node=0x7f26eb7e7ee0, accessMtd=, recheckMtd=) at /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execScan.c:132 #12 0x7f26ea670da8 in ExecProcNode (node=0x7f26eb7e7ee0) at /opt/src/postgresql-9.1-9.1.6/build/../src/backend/executor/execProcnode.c:416 #13 0x7f26ea66fbf2 in ExecutePlan (dest=, direction=, numberTuples=, sendTuples=, operation=, planstate=, estate=) 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:
