Re: C function migration from 9.2 to 9.5

Hi

2016-03-03 15:12 GMT+01:00 Michael Omotayo Akinde <michaeloa(at)met(dot)no>:

> Hi,
>
> We've been having a Postgresql database with some custom C functionality
> happily running for many years now. It's been running on 9.2, and we wish
> to upgrade this to the latest version. However, we're seeing some issues
> with the database process crashing each time.
>
> A simplified, minimal example of the stuff that seems to get us into
> trouble:
>

It is strange. I tested your code, and it is working without any problems

compiled by gcc on Linux 64bit

Regards

Pavel

>
> SQL definitions:
> ----
>
> CREATE TYPE sessionData AS ( a int4, b int4, c int4 );
>
> CREATE OR REPLACE FUNCTION
> __WCI_SCHEMA__.getSessionData
> ()
> RETURNS sessionData AS
> 'db_libdir/db_lib', 'session_get'
> LANGUAGE 'C' STABLE;
>
> ----
> Function definition:
> ----
>
> PG_FUNCTION_INFO_V1 (session_get);
> Datum session_get(PG_FUNCTION_ARGS) {
> Datum ret = packSessionData( 0, 0, 0, fcinfo);
> return ret;
> }
>
> Datum packSessionData( int a, int b, int c, FunctionCallInfo fcinfo )
> {
> TupleDesc td;
> if ( get_call_result_type( fcinfo, NULL, & td ) != TYPEFUNC_COMPOSITE )
> {
> ereport( ERROR,
> ( errcode( ERRCODE_DATA_EXCEPTION ),
> errmsg( "\'packSessionData\': Function returning record
> called in context that cannot accept type record" ) ) );
> }
> td = BlessTupleDesc( td );
>
> Datum * ret = ( Datum * ) palloc( 3 * sizeof( Datum ) );
> bool isNull[ 3 ] = {false, false, false};
>
> ret[ 0 ] = Int32GetDatum( a );
> ret[ 1 ] = Int32GetDatum( b );
> ret[ 2 ] = Int32GetDatum( c );
>
> HeapTuple ht = ( HeapTuple ) heap_form_tuple( td, ret, isNull );
> return HeapTupleGetDatum( ht );
> }
>
> ----
>
> Running "select getSessionData()" with this code crashes the database.
> Pretty much identical code worked fine in 9.2; it's only from 9.3+ we run
> into trouble. I'm sure we're overseeing something completely basic that has
> changed in 9.3, but having trouble seeing what it is. A little help would
> be appreciated.
>
> Regards,
>
> Michael A.
>
>