Thread: Bug #922: PANIC: open of /scratch/production_2/pg_clog/0996 failed: No such file or directory

A. Hackmann (andre.hackmann@ntlworld.com) reports a bug with a severity of 1
The lower the number the more severe it is.

Short Description
PANIC:  open of /scratch/production_2/pg_clog/0996 failed: No such file or directory

Long Description
Hi,
I'm loading aprrox. 20GB into a Postgresql 7.3.2 db (using COPY command). Copying works fine, but when I tried to
createindices, I get the error message above. Postmaster is running under Red Hat Linux 7.1 on a dual Xeon machine
having2GB RAM. 1 GB ist reserved for shared memory, where 600Mb is used for this particular db instance. I changed wlog
parameters,but this had no effect. Source has been compilied on gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85).  

Thanks,
  Andre.

Sample Code


No file was uploaded with this report

pgsql-bugs@postgresql.org writes:
> PANIC:  open of /scratch/production_2/pg_clog/0996 failed: No such file or directory

I'd wonder about hardware problems, especially if this is a new server.
Messages of the above type are one of the most common consequences when
a data page has been trashed by hardware misfeasance.

(While I wouldn't sit here and swear that it couldn't be a software
problem, all of the cases I've been able to examine seemed to be
hardware failures...)

            regards, tom lane

Hi,

The server (IBM) is one year old (I think).
Anyway, I found something like a workaround:
If I vacuum before executing my index script (after my loading
script has terminated), or after other huge data movements, the server
doesn't crash. So, is this typical for hardware failures?

Thanks,
  Andre.


On Sun, 30 Mar 2003, Tom Lane wrote:

>
> I'd wonder about hardware problems, especially if this is a new server.
> Messages of the above type are one of the most common consequences when
> a data page has been trashed by hardware misfeasance.
>
> (While I wouldn't sit here and swear that it couldn't be a software
> problem, all of the cases I've been able to examine seemed to be
> hardware failures...)
>
>             regards, tom lane
>