Thread: 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=<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

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=<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.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

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

On Fri, Nov 16, 2012 at 11:09 AM, Sébastien Lardière
<slardiere@hi-media.com> 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