Re: backend reset of database

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);

To produce the above back trace I executed the following from a psql window:

select pcm_getmiles_s('sparta,nc', 'buffalo,ny',0);

> It seems fairly
> unlikely that it would be calling FileRead() if not.

I find that unlikely as well.

> Do you have any
> other Postgres-specific libraries loaded into the backend?

I don't believe so.

> The immediate issue is that FileRead() is being passed a bogus file
> number, which might suggest an unexpected change in the contents of
> a struct or something like that, but I see no record of any such changes
> in the CVS log between 7.4.13 and 7.4.16.

This is what threw me as well.  It definitely looks like something
internal to Postgresql.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin