Skip site navigation (1) Skip section navigation (2)

Re: process exited with status 11 after XLogFlush: request is not satisfied

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 20:23:24
Message-ID: 4913.1012508604@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-general
"Bjoern Metzdorf" <bm(at)turtle-entertainment(dot)de> writes:
> If I do the same "select where ctid"-test on all ctid's of neighboured
> tuples ("select ctid from players order by id limit 20,81270;") it is the
> same (works).

Um, the "order by id" is not accomplishing much here except to confuse
the issue.  Tuples adjacent in id order are not necessarily anywhere
near each other physically.  Why don't you just do

		select ctid,* from players limit N

Since this is a heapscan it will return the results in ctid order.

An offset isn't going to do much except confuse the issue either,
because the tuples skipped by the offset are still fetched and might
still provoke a crash.

Don't forget also that you *must* select the columns.  "select ctid from..."
alone will probably not crash no matter how badly the body of the tuple
is mangled, 'cause it ain't gonna look at the body.

What I'd do to locate the bad tuple(s) is

1. Home in on an approximate value of N that separates where

		select * from players limit N

crashes vs. where it doesn't crash.

2. Get the ctid's of the tuples around this point, eg

		select ctid from players offset N-100 limit 200

As indicated, you can probably retrieve the ctids even if the tuples
are busted.

3. Probe these tuples individually using

		select * from players where ctid = '(m,n)';


Or you could just set up a script that does
		select ctid from players
and then tries to retrieve each one individually by ctid.  A tad tedious
but easily automated.  If you suspect there might be corruption in
several different areas of the table then you'll end up doing this anyway.

			regards, tom lane

In response to

pgsql-general by date

Next:From: Stephan SzaboDate: 2002-01-31 20:26:13
Subject: Re: Drop Foreign Key
Previous:From: Darren FergusonDate: 2002-01-31 20:20:04
Subject: Re: going crazy with serial type

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group