Re: Large index operation crashes postgres - Mailing list pgsql-general

From Frans Hals
Subject Re: Large index operation crashes postgres
Date
Msg-id 39af1ed21003251302k779c513di9b6fb3bfee887f2@mail.gmail.com
Whole thread Raw
In response to Re: Large index operation crashes postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom,

ran a CREATE INDEX to the gdb operated postmaster.
Nothing new due to missing debugging libraries, so this might not help:

Reading symbols from /usr/bin/postmaster...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install
postgresql-server-8.3.9-1PGDG.f12.x86_64
(gdb) run
Starting program: /usr/bin/postmaster
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 2869.
LOG:  database system was interrupted; last known up at 2010-03-24 05:51:12 PDT
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  redo starts at CF/D482490
LOG:  unexpected pageaddr CE/AD490000 in log file 207, segment 13,
offset 4784128
LOG:  redo done at CF/D48FB80
Detaching after fork from child process 2870.
Detaching after fork from child process 2871.
Detaching after fork from child process 2872.
LOG:  database system is ready to accept connections
Detaching after fork from child process 2996.
Detaching after fork from child process 3682.
Detaching after fork from child process 3685.
Detaching after fork from child process 3687.
Detaching after fork from child process 3688.
Detaching after fork from child process 3690.
Detaching after fork from child process 3691.
Detaching after fork from child process 3696.
Detaching after fork from child process 3698.
Detaching after fork from child process 3702.
Detaching after fork from child process 3706.
Detaching after fork from child process 3710.
LOG:  background writer process (PID 2870) was terminated by signal 9: Killed
LOG:  terminating any other active server processes
LOG:  statistics collector process (PID 2872) was terminated by signal 9: Killed
Detaching after fork from child process 5595.
FATAL:  the database system is in recovery mode

Is there anything meaningful for you?
Does it makes sense to install the debuginfos to catch the problem? If
yes, I may do so.

Paul asked me, to check another function of the postgis set for a
memory leak. I will try this now.

Thanks & regards
Frans

2010/3/24 Tom Lane <tgl@sss.pgh.pa.us>:

> Can you provide a stack trace from the crash?
>

pgsql-general by date:

Previous
From: Chris Barnes
Date:
Subject: Does anyone use in ram postgres database?
Next
From: Merlin Moncure
Date:
Subject: Re: Does anyone use in ram postgres database?