Обсуждение: Bug #922: PANIC: open of /scratch/production_2/pg_clog/0996 failed: No such file or directory
Bug #922: PANIC: open of /scratch/production_2/pg_clog/0996 failed: No such file or directory
От
pgsql-bugs@postgresql.org
Дата:
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 >