From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Bjoern Metzdorf" <bm(at)turtle-entertainment(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: process exited with status 11 after XLogFlush: request is not satisfied |
Date: | 2002-01-31 18:44:33 |
Message-ID: | 4174.1012502673@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Bjoern Metzdorf" <bm(at)turtle-entertainment(dot)de> writes:
> If we now do a
> "select ctid,oid,* from table order by id limit 1,81274;" (which works
> flawlessly)
> we see, that this tuple is in ctid (5864,12).
One thing to watch out for is that I believe "select ... limit" fetches
one more tuple than it actually needs to return. Normally this doesn't
matter but with a crashing issue it might. I would recommend using
select ctid,* from table where ctid = '(page,item)'
to make absolutely sure that you know which ctid is the bad tuple (if no
crash, you got the wrong one), and then delete by ctid to get rid of it.
It's entirely possible that several tuples on the same page are all
corrupted, which is the main reason why ctid is so helpful in this
situation --- you can see directly whether the tuples are in the same
page or not. But I wouldn't delete stuff at random. If you can select
it without a crash then it's OK.
I would only consider using dd if it looked like the page header is
broken (symptom: page appears to contain many more tuples than could
possibly fit, and all but the first few are obviously completely
garbage).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ben-Nes Michael | 2002-01-31 19:08:42 | Re: unique & update |
Previous Message | Bjoern Metzdorf | 2002-01-31 18:32:30 | Re: process exited with status 11 after XLogFlush: request is not satisfied |