Обсуждение: BUG #11761: range_in dosn't work via direct functional call

The following bug has been logged on the website:

Bug reference:      11761
Logged by:          Oleg
Email address:      olegjobs@mail.ru
PostgreSQL version: 9.3.2
Operating system:   Ubuntu 64 14.04
Description:

This function test_ext_get_range(cstring) returns int4range:

Datum test_ext_get_range(PG_FUNCTION_ARGS)
{
   char *ts = PG_GETARG_CSTRING(0);

   return DirectFunctionCall3(range_in, CStringGetDatum(ts),
ObjectIdGetDatum(3904), Int32GetDatum(0);
}
In psql:
select test_ext_get_range('[1,1]');
error:
connection to the server was lost.

it seems to me that some memory problems because of "The range I/O functions
need a bit more cached info than other range
 * functions, so they store a RangeIOData struct in fn_extra, not just a
 * pointer to a type cache entry. "

On 10/22/2014 08:27 PM, olegjobs@mail.ru wrote:
> This function test_ext_get_range(cstring) returns int4range:
>
> Datum test_ext_get_range(PG_FUNCTION_ARGS)
> {
>     char *ts = PG_GETARG_CSTRING(0);
>
>     return DirectFunctionCall3(range_in, CStringGetDatum(ts),
> ObjectIdGetDatum(3904), Int32GetDatum(0);
> }
> In psql:
> select test_ext_get_range('[1,1]');
> error:
> connection to the server was lost.
>
> it seems to me that some memory problems because of "The range I/O functions
> need a bit more cached info than other range
>   * functions, so they store a RangeIOData struct in fn_extra, not just a
>   * pointer to a type cache entry. "

Yeah, DirectFunctionCall cannot be used with range_in. Use FunctionCall3
instead. See this comment in fmgr.c, above DirectFunctionCall1Coll:

> /*
>  * These are for invocation of a specifically named function with a
>  * directly-computed parameter list.  Note that neither arguments nor result
>  * are allowed to be NULL.  Also, the function cannot be one that needs to
>  * look at FmgrInfo, since there won't be any.
>  */

range_in needs to look at FmgrInfo.

- Heikki

2014-10-24 15:08 GMT+02:00 Heikki Linnakangas <hlinnakangas@vmware.com>:

> On 10/22/2014 08:27 PM, olegjobs@mail.ru wrote:
>
>> This function test_ext_get_range(cstring) returns int4range:
>>
>> Datum test_ext_get_range(PG_FUNCTION_ARGS)
>> {
>>     char *ts = PG_GETARG_CSTRING(0);
>>
>>     return DirectFunctionCall3(range_in, CStringGetDatum(ts),
>> ObjectIdGetDatum(3904), Int32GetDatum(0);
>> }
>> In psql:
>> select test_ext_get_range('[1,1]');
>> error:
>> connection to the server was lost.
>>
>> it seems to me that some memory problems because of "The range I/O
>> functions
>> need a bit more cached info than other range
>>   * functions, so they store a RangeIOData struct in fn_extra, not just a
>>   * pointer to a type cache entry. "
>>
>
> Yeah, DirectFunctionCall cannot be used with range_in. Use FunctionCall3
> instead. See this comment in fmgr.c, above DirectFunctionCall1Coll:
>

There is a special "InputFunctionCall"

Regards

Pavel


>
>  /*
>>  * These are for invocation of a specifically named function with a
>>  * directly-computed parameter list.  Note that neither arguments nor
>> result
>>  * are allowed to be NULL.  Also, the function cannot be one that needs to
>>  * look at FmgrInfo, since there won't be any.
>>  */
>>
>
> range_in needs to look at FmgrInfo.
>
> - Heikki
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>

FmgrInfo fmgr;

Oid func_id = fmgr_internal_function("range_in");

fmgr_info(func_id, &fmgr);

Datum result = FunctionCall3(&fmgr, CStringGetDatum("(1,1)"), ObjectIdGetDatum(3904), Int32GetDatum(0));
And one more question, for example, I do some memory allocation via palloc in _PG_Init().
Is this memory preserve for all life time after library is loaded into postgresql process?

Other case, for example, I have this code in dynamic lib:

char *global_init;
char *global;

void _PG_init(void)
{
   global_init = (char *) palloc(10);
}

Datum f (PG_FUNCTION_ARGS)
{
   if (!global)
   {
      global  = (char*) palloc (10);
   }
   *global = '\0'; // is it ok when i call "f" several times?
   *global_init = '\0'; // is it ok when i call "f" several times?
} 






Fri, 24 Oct 2014 15:52:36 +0200 от Pavel Stehule <pavel.stehule@gmail.com>:

2014-10-24 15:08 GMT+02:00 Heikki Linnakangas <hlinnakangas@vmware.com>:

On 10/22/2014 08:27 PM, olegjobs@mail.ru wrote:

This function test_ext_get_range(cstring) returns int4range:

Datum test_ext_get_range(PG_FUNCTION_ARGS)
{
    char *ts = PG_GETARG_CSTRING(0);

    return DirectFunctionCall3(range_in, CStringGetDatum(ts),
ObjectIdGetDatum(3904), Int32GetDatum(0);
}
In psql:
select test_ext_get_range('[1,1]');
error:
connection to the server was lost.

it seems to me that some memory problems because of "The range I/O functions
need a bit more cached info than other range
  * functions, so they store a RangeIOData struct in fn_extra, not just a
  * pointer to a type cache entry. "

Yeah, DirectFunctionCall cannot be used with range_in. Use FunctionCall3 instead. See this comment in fmgr.c, above DirectFunctionCall1Coll:

There is a special "InputFunctionCall"

Regards

Pavel

 

/*
 * These are for invocation of a specifically named function with a
 * directly-computed parameter list.  Note that neither arguments nor result
 * are allowed to be NULL.  Also, the function cannot be one that needs to
 * look at FmgrInfo, since there won't be any.
 */

range_in needs to look at FmgrInfo.

- Heikki


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

=?UTF-8?B?RHVuYXVza2FzIE9sZWc=?= <olegjobs@mail.ru> writes:
> And one more question, for example, I do some memory allocation via palloc in _PG_Init().
> Is this memory preserve for all life time after library is loaded into postgresql process?

Probably not --- CurrentMemoryContext would most likely be pointing at a
statement-lifespan context.  If you want that behavior, I'd recommend
explicitly allocating in TopMemoryContext.

(Also, you would not be needing to ask that question if you were using
an --enable-cassert build for testing.  Which is *highly* recommended
when developing C code for Postgres.)

            regards, tom lane