Crash on SRF execution

Itai <itaid@outlook.com> writes:

I'm attempting to program a simple SRF function but it constantly crashes (details and code below).
Any idea why?

Looks like you're pallocing some stuff in the calling context (ie, a
short-lived context) during the first execution and expecting it to
still be there in later executions. You'd need to allocate those
data structures in the multi_call_memory_ctx instead.

regards, tom lane

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

Hi,

On 2015-03-15 17:40:11 +0200, Itai wrote:

I'm attempting to program a simple SRF function but it constantly crashes (details and code below).

Any idea why?

if (SRF_IS_FIRSTCALL())
{
length = 4000;
base_num = 1203000000;
list = (NumberList *)palloc(sizeof(NumberList));
list->pp_numbers = (Number **)palloc(sizeof(Number*) * length);
list->length = length;
i = 0;
for (; i < length; i++)
{
num = (Number *)palloc(sizeof(Number));
num->value = base_num + i;
num->is_even = ((base_num + i) % 2 == 0) ? 1 : 0;
list->pp_numbers[i] = num;
}
ereport(INFO, (errmsg("----------- data source -----------")));
i = 0;
for (; i < length; i++)
{
ereport(INFO, (errmsg("value: %d", list->pp_numbers[i]->value)));
ereport(INFO, (errmsg("is_even: %d", list->pp_numbers[i]->is_even)));
}

funcctx = SRF_FIRSTCALL_INIT();
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
funcctx->user_fctx = list;
funcctx->max_calls = list->length;
if (get_call_result_type(fcinfo, NULL, &funcctx->tuple_desc) != TYPEFUNC_COMPOSITE)
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("check if sql function definition returns SETOF record")));

BlessTupleDesc(funcctx->tuple_desc);
MemoryContextSwitchTo(oldcontext);
}

The palloc() for list above is in the per call memory context, but you
use it across several calls. You should allocate it in the multi call
context you use some lines below.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

Thanks for the quick response!! :)
But I don't get it... isn't:
if (SRF_IS_FIRSTCALL()){
}
the iterator one time
"initialization block" where I setup the data to be iterated
upon?

Can you please elaborate on how should I fix this? I'm probably missing something basic...

Hi,

On 2015-03-15 17:59:39 +0200, Itai wrote:

Thanks for the quick response!! :)
But I don't get it... isn't:
if (SRF_IS_FIRSTCALL()){
}
the iterator one time
"initialization block" where I setup the data to be iterated
upon?

Can you please elaborate on how should I fix this? I'm probably missing something basic...

if (SRF_IS_FIRSTCALL())
{
length = 4000;
base_num = 1203000000;
list = (NumberList *)palloc(sizeof(NumberList));
list->pp_numbers = (Number **)palloc(sizeof(Number*) * length);

You allocate memory in the per call context here.

list->length = length;
i = 0;
for (; i < length; i++)
{
num = (Number *)palloc(sizeof(Number));
num->value = base_num + i;
num->is_even = ((base_num + i) % 2 == 0) ? 1 : 0;
list->pp_numbers[i] = num;
}
ereport(INFO, (errmsg("----------- data source -----------")));
i = 0;
for (; i < length; i++)
{
ereport(INFO, (errmsg("value: %d", list->pp_numbers[i]->value)));
ereport(INFO, (errmsg("is_even: %d", list->pp_numbers[i]->is_even)));
}

funcctx = SRF_FIRSTCALL_INIT();
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);

Because you only switch the memory context here. Move this up, to the
beginning of the SRF_IS_FIRSTCALL block. Before the palloc()s.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

Fantastic! That solved this problem.

However I still get a crash if I change:

is_even to bool num->is_even = ((base_num + i) % 2 == 0) ? true : false; retvals[1] = BoolGetDatum(list->pp_numbers[call_cntr]->is_even); CREATE OR REPLACE FUNCTION pg_srf(OUT value integer, OUT is_even bit) RETURNS SETOF recordAS 'pg_srf.so', 'pg_srf'LANGUAGE CSTRICTIMMUTABLE;

Thanks Tom.

Assuming the SRF had a parameter, would this be a correct approach
(considering the iterative model) to bail-out early?

if (SRF_IS_FIRSTCALL())
{
int i;

if (get_call_result_type(fcinfo, NULL, &funcctx->tuple_desc) !=
TYPEFUNC_COMPOSITE)
{
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("Check if sql function definition returns SETOF
record")));
return;
}

if (PG_ARGISNULL(0))
{
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("Null value not allow for ...")));
return;
}

if((i = PG_GETARG_INT32(0)) != 'WHATEVER')
{
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("Null value not allow for ...")));
return;
}

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Sunday, March 15, 2015 5:50 PM
To: Itai
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Crash on SRF execution

Itai <itaid@outlook.com> writes:

I'm attempting to program a simple SRF function but it constantly crashes

(details and code below).

Any idea why?

Looks like you're pallocing some stuff in the calling context (ie, a
short-lived context) during the first execution and expecting it to still be
there in later executions. You'd need to allocate those data structures in
the multi_call_memory_ctx instead.

regards, tom lane

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