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

--- 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