Re: FATAL 2: open of /var/lib/pgsql/data/pg_clog/0EE3

From: Jeff Eckermann <jeff_eckermann(at)yahoo(dot)com>
To: Dmitry Tkach <dmitry(at)openratings(dot)com>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: FATAL 2: open of /var/lib/pgsql/data/pg_clog/0EE3
Date: 2003-07-18 19:32:42
Message-ID: 20030718193242.70215.qmail@web20810.mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


--- Dmitry Tkach <dmitry(at)openratings(dot)com> wrote:
> scott.marlowe wrote:
>
> >>Why doesn't it complain after I restart it then?
> >>
> >>
> >
> >Why should it? If the problem is corrupted data in
> an index / table
> >/system table etc... you won't see an error until
> it accesses the
> >table/index etc... that's causing the problem.
> >
> >
> Right...
>
> So,
>
> 1) I do
>
> analyze mytable;
>
> ,.. it crashes.
>
> 2) I do it again:
>
> analyze mytable;
>
> ... it crashes.
>
> 3) I restart the server manually, and try again
>
> analyze mytable;
>
> ... it *works*
>
> 4) I let it run for a while, then try again:
>
> analyze mytable;
>
> ... it crashes.
>
> So, it looks like, if there is some data structure
> or a catalog screwed
> up, it is not screwed up by 7.2.1 earlier, it is
> *being* screwed up
> somewhere between #3 and #4 above...
>
> Dima

I *think* (ignorance showing here) that "analyze" only
samples data, so the bad data will not necessarily be
touched on a given pass.

I went through the problem too (with version 7.2.1),
and went through the archives pretty thoroughly. The
problem is caused by a spurious xid value in some
record somewhere. The theories offered on the cause
of this were:
* hardware problems
* an unknown bug in 7.2, fixed around 7.2.3(?)

The second theory looked likely, because there was a
rash of reports for versions in the 7.2.0 - 7.2.1
range, but none for 7.2.4 (until now). The bug theory
was never investigated, because no-one was able to
supply a reproducible test case, and the problem
seemed to be fixed by an upgrade anyway.

So the dump and restore should have fixed the problem
for you, because xid values are not dumped. And if
you had a bad xid value in your database, the dump
should have failed anyway. All very mysterious.
Search the archives for plenty more on this.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Eckermann 2003-07-18 19:37:17 Re: Access 97 DB to Postgres Migration Questions
Previous Message Andrew Ayers 2003-07-18 19:32:10 [Fwd: Re: Access 97 DB to Postgres Migration Questions]