From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mark Greenbank" <mark(dot)greenbank(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: server closed the connection unexpectedly |
Date: | 2006-10-06 16:10:07 |
Message-ID: | 21455.1160151007@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Mark Greenbank" <mark(dot)greenbank(at)gmail(dot)com> writes:
> [ select count(*) from email_queue leads to ]
> LOG: server process (pid 26548) was terminated by signal 11
If this is repeatable then it probably indicates corrupt data on-disk
(which 7.3.2 is mostly lacking any defenses for). The trick is to find
and delete the corrupted rows or pages. You can generally get somewhere
by a process of binary search, ie, find the largest N such that
"select ctid,* from email_queue limit N" doesn't fail. The last ctid
you can extract this way will be one or two before the (first) bad row.
Given that it's a count(*) that's failing, the problem is probably with
a page or tuple header and not any individual data field, so you might
not have any good recovery option beyond zeroing the whole page
containing the error. See the mailing list archives for past
discussions of recovering from data corruption for more info.
> The worrying bit (at least to my uneducated eye) is the line:
> LOG: ReadRecord: record with zero length at D/72C79AD4
That's normal operation, don't worry about it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-06 16:12:40 | Re: Europe/Moscow timezone |
Previous Message | Brandon Metcalf | 2006-10-06 15:52:04 | Re: Europe/Moscow timezone |