From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Janning Vygen <vygen(at)kicktipp(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: PANIC: corrupted item pointer |
Date: | 2012-04-06 21:49:28 |
Message-ID: | 1333748968.4738.5.camel@sussancws0025 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, 2012-03-31 at 13:21 +0200, Janning Vygen wrote:
> The OS was installed a few days before, the i installed the postgresql
> instance. I configured my setup with a backup server by WAL archiving.
> Then i tested some things and i played around with pg_reorg (but i
> didn't use ist till then) then i dropped the database, shut down my app,
> installed a fresh dump and restarted the app.
Hmm... I wonder if pg_reorg could be responsible for your problem? I
know it does a few tricky internal things.
> Is it still worth to make the copy now? At the moment everything is
> running fine.
Probably not very useful now.
> No, i didn't found any in my postgresql dirs. Should i have a core file
> around when i see a segmentation fault? What should i look for?
It's an OS setup thing, but generally a crash will generate a core file
if it is allowed to. Use "ulimit -c unlimited" on linux in the shell
that starts postgresql and I think that will work. You can test it by
manually doing a "kill -11" on the pid of a backend process.
> I have never done it before. But as everything runs fine at the moment
> it's quite useless, isn't it?
I meant a backtrace from the core file. If you don't have a core file,
then you won't have this information.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Nolan | 2012-04-06 21:54:54 | Re: 9.1.3 Standby catchup mode |
Previous Message | Greg Sabino Mullane | 2012-04-06 20:14:29 | Re: Using DEFAULT as a parameter value with PQexecPrepare() |