Re: Version 7.2.3 unrecoverable crash on missing pg_clog

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andy Osborne <andy(at)sift(dot)co(dot)uk>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Version 7.2.3 unrecoverable crash on missing pg_clog
Date: 2003-01-09 14:57:51
Message-ID: 29509.1042124271@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andy Osborne <andy(at)sift(dot)co(dot)uk> writes:
> One of our databases crashed yesterday with a bug that looks
> a lot like the non superuser vacuum issue that 7.2.3 was
> intended to fix, although we do our vacuum with a user that
> has usesuper=t in pg_user so I guess it's not that simple.

> FATAL 2: open of /u0/pgdata/pg_clog/0726 failed: No such file or directory

What range of file names do you actually see in pg_clog?

The fixes in 7.2.3 were for cases that would try to access
already-removed clog segments (file numbers less than what's present).
In this case the accessed file name is large enough that I'm thinking
the problem is due to a garbage transaction number being passed to the
transaction-status-check code. So my bet is on physical data corruption
in the table that was causing the problem. It turns out that the first
detectable symptom of a trashed tuple header is often a failure like
this :-(.

You didn't happen to make a physical copy of the news table before
dropping it, did you? It'd be interesting to examine the remains.
So far, the cases I have seen like this all seem to be due to hardware
faults, but we've seen it just often enough to make me wonder if there
is a software issue too.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andy Osborne 2003-01-09 15:12:24 Re: Version 7.2.3 unrecoverable crash on missing pg_clog
Previous Message Tom Lane 2003-01-09 14:28:04 Re: Bug #868: temp schema can't be clean automatically