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