Re: Dying PostgreSQL backend

From: "otisg" <otisg(at)iVillage(dot)com>
To: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Dying PostgreSQL backend
Date: 2002-05-08 00:03:55
Message-ID: 038a01c1f623$d83191a0$6ec8010a@mail2world.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hello,

> What I'd recommend doing is gdb'ing the core dump file to get a stack
> trace; that would give us some clue what's wrong. And you could do
> "p debug_query_string" to see what query made it crash.
>
> If you do not find a core file in the database subdirectory
> ($PGDATA/base/yourdbnumber/core) then you are probably running the
> postmaster with "ulimit -c 0" which disables core dumps. Restart
> it with environment "ulimit -c unlimited".

Yes, I fixed that.

Unfortunately I can't gdb to look into the core file:
(gdb) p debug_query_string
No symbol table is loaded. Use the "file" command.
(gdb) file /tmp/core4
"/tmp/core4": not in executable format: File format not recognized
(gdb)

Any ideas?

I did, however, see this in the syslogd log at the time of core dump:

/usr/bin/postmaster child[4014]: starting with (postgres -d16 -v131072
-p mydb )
invoking IpcMemoryCreate(size=2015232)

The first line I had seen before (every few seconds, since my
application makes 5-7 updates per second), but never the second one.
This was the first time.
Maybe it means something to those familiar with the guts of PostgreSQL.

Thanks,
Otis
_______________________________________________________________
Sign up for FREE iVillage newsletters <http://s.ivillage.com/rd/16705> .
>From health and pregnancy to shopping and relationships, iVillage
has the scoop on what matters most to you.

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2002-05-08 05:59:46 Re: db recovery (FATAL 2)
Previous Message Hal Lynch 2002-05-07 22:09:44 batch operations