Re: backend reset of database

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Geoffrey <esoteric(at)3times25(dot)net>
Cc: pgsql-general(at)postgresql(dot)org, Terry Lee Tucker <terry(at)leetuckert(dot)net>, John Allgood <john(at)turbocorp(dot)com>, "j(dot) >> \"J(dot) D(dot) Pearson\"" <jpearson(at)turbocorp(dot)com>
Subject: Re: backend reset of database
Date: 2007-04-09 17:13:07
Message-ID: 29454.1176138787@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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? It seems fairly
unlikely that it would be calling FileRead() if not. Do you have any
other Postgres-specific libraries loaded into the backend?

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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Geoffrey 2007-04-09 17:49:58 Re: backend reset of database
Previous Message Geoffrey 2007-04-09 16:30:06 backend reset of database