Re: Backend died abnormally - postgresql 7.2.1-5 - Mailing list pgsql-general

From Rick Eicher II
Subject Re: Backend died abnormally - postgresql 7.2.1-5
Date
Msg-id 000001c22cde$53e05d90$0a01a8c0@rick
Whole thread Raw
In response to Re: Backend died abnormally - postgresql 7.2.1-5  (nconway@klamath.dyndns.org (Neil Conway))
Responses Re: Backend died abnormally - postgresql 7.2.1-5
List pgsql-general
> On Tue, Jul 16, 2002 at 09:51:48AM -0500, Rick Eicher II wrote:
> > > Is the crash reproducible, and if so, can you post the query or
> > > situation that causes the crash to occur? (you can enable query
> > > logging with debug_print_query in postgresql.conf)
> >
> > The crash is reproducible. Some examples of a query would be:
> >
> >    Select * from cust_main where last='smith';
> >    Select * from cust_main;
>
> Are there any additional errors in the logs?
>
> With an error that fundamental, I'd suspect hardware problems, namely
> bad RAM. Would it be possible to run memtest86 on the machine?
>
> > I do have some joins queries but I seem to get this error with any
of
> > query. If I issue the same query four times I will get the error one
> > time. I have uncommented this line (and others) in postgresql.conf
but
> > do not get any log entries after restart.
> >
> > >
> > > Is there a core file in one of your database directories -- and if
> > > so, can you get a backtrace from it using gdb? It might also be
> > > useful to get a backtrace from a debugging build (--enable-debug).
> >
> > No core file.
>
> Are you sure your system is setup to allow core dumps -- i.e.
> does "ulimit -c" produce "unlimited"?

[root@nemisis root]# ulimit -c
1000000

> Also, make sure you're looking in the right place for
> core files ($PGDATA/base/$oid_of_db/core)

I was not looking in the right place before. But still no core files
found.

> > Should I get the source and build it instead of using rpms?

Trying to decide what is the best plan of attack since this is a
production machine. But I think I will run the memtest86 on it first.

> Might be a good bet -- at the least, it should produce a more
> helpful backtrace.
>
> Cheers,
>
> Neil
>
> --
> Neil Conway <neilconway@rogers.com>
> PGP Key ID: DB3C29FC




pgsql-general by date:

Previous
From: "João" Paulo Batistella
Date:
Subject: Constraint
Next
From: Chris Albertson
Date:
Subject: Re: Pushing PostgreSQL to the Limit (urgent!)