Re: backend reset of database - Mailing list pgsql-general

From Magnus Hagander
Subject Re: backend reset of database
Date
Msg-id 461A8556.7010900@hagander.net
Whole thread Raw
In response to Re: backend reset of database  (Geoffrey <esoteric@3times25.net>)
Responses Re: backend reset of database  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Geoffrey wrote:
> Tom Lane wrote:
>> Geoffrey <esoteric@3times25.net> writes:
>>> A backtrace against this process produces:
>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0814acc9 in FileAccess (file=168481968) at fd.c:717
>>> 717             if (FileIsNotOpen(file))
>>> (gdb) bt
>>> #0  0x0814acc9 in FileAccess (file=168481968) at fd.c:717
>>> #1  0x0814b2e7 in FileRead (file=168481968, buffer=0xbff816ce "",
>>> amount=2)
>>>      at fd.c:972
>>> #2  0x00203ecc in ?? ()
>>
>>> I'm assuming that the portion of the backtrace from frame 2-12 is
>>> likely produced from the pcmiler binaries as we do not have source
>>> and they don't contain debugging symbols.
>>
>> Is pcmiler a Postgres-specific backend extension?
>
> No.  It's a standalone application that provides an api to build calls
> into there product from other applications.  What we've done is created
> functions that are called from the database that use their api.  for
> example:
>
> CREATE OR REPLACE FUNCTION pcm_getmiles_s(text,text,integer)
>     RETURNS float8 AS '/esc/pgrnd/prog/libpcmiler'
>     LANGUAGE 'c' WITH (isStrict);

Is this function actually a PostgreSQL callable function? Or is it just
a general C function along the line of
float pcm_getmiles_s(char*, char*, int)
?

If it's a general C function, you'll need to write a wrapper function
that calls it, and returns the data, using the PostgreSQL macros to
extract the parameters.

//Magnus


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: backend reset of database
Next
From: Tom Lane
Date:
Subject: Re: backend reset of database