From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Daniel Caune" <daniel(dot)caune(at)ubisoft(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: [SQL] PostgreSQL server terminated by signal 11 |
Date: | 2006-07-28 16:31:44 |
Message-ID: | 25231.1154104304@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-sql |
"Daniel Caune" <daniel(dot)caune(at)ubisoft(dot)com> writes:
> The statement "copy gslog_event to stdout;" leads to "ERROR: invalid memory alloc request size 4294967293" after awhile.
> ...
> I did other tests on some other tables that contain less data but that seem also corrupted:
This is a bit scary as it suggests a systemic problem. You should
definitely try to find out exactly what the corruption looks like.
It's usually not hard to home in on where the first corrupted row is
--- you do
SELECT ctid, * FROM tab LIMIT n;
and determine the largest value of n that won't trigger a failure.
The corrupted region is then just after the last ctid you see.
You can look at those blocks with "pg_filedump -i -f" and see if
anything pops out. Check the PG archives for previous discussions
of dealing with corrupted data.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Frost | 2006-07-28 18:01:35 | Re: Postgres replication solutions |
Previous Message | Jeff Frost | 2006-07-28 16:21:42 | mrtg xact/sec plugin |
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Jones | 2006-07-28 16:43:25 | Re: Disk is full, what's cool to get rid of? |
Previous Message | Daniel Caune | 2006-07-28 16:09:48 | Re: [SQL] PostgreSQL server terminated by signal 11 |