Re: backend reset of database

Geoffrey wrote:
> Tom Lane wrote:
>> Geoffrey <esoteric(at)3times25(dot)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