Thread: HELP: pg_clog file not found error

HELP: pg_clog file not found error

From
Date:
When my server is under heavy load I sometimes get this error (see below),
and the backend restarts.

Does anyone know what causes this?  Could it be a max number of filehandles
reached?  If so how do I increase it?  (I know I have lots of disk space on
that partition)

I am running postgres: postmaster (PostgreSQL) 7.2.1
on Redhat 6.2 with the original (inital) kernel.

Any ideas greatly appreciated.

Thanks

...
DEBUG:  query: select btrim($1, ' ')
DEBUG:  query: select btrim($1, ' ')
FATAL 2:  open of /usr/local/pgsql/data/pg_clog/0522 failed: No such file or
dir
ectory
DEBUG:  proc_exit(2)
DEBUG:  shmem_exit(2)
DEBUG:  exit(2)
DEBUG:  reaping dead processes
DEBUG:  child process (pid 2432) exited with exit code 2
DEBUG:  server process (pid 2432) exited with exit code 2
DEBUG:  terminating any other active server processes
DEBUG:  CleanupProc: sending SIGQUIT to process 2520
DEBUG:  CleanupProc: sending SIGQUIT to process 2395
NOTICE:  Message from PostgreSQL backend:
        The Postmaster has informed me that some other backend
        died abnormally and possibly corrupted shared memory.
        I have rolled back the current transaction and am
        going to terminate your database system connection and exit.
        Please reconnect to the database system and repeat your query.
DEBUG:  reaping dead processes

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
terry@greatgulfhomes.com



Re: HELP: pg_clog file not found error

From
Tom Lane
Date:
<terry@ashtonwoodshomes.com> writes:
> When my server is under heavy load I sometimes get this error (see below),
> and the backend restarts.

> FATAL 2:  open of /usr/local/pgsql/data/pg_clog/0522 failed: No such file or
> directory

Is it repeatable --- that is, do you see it again if you run a VACUUM
afterwards?

If not, I'd have to speculate that you have bad RAM (or less likely, a
bad disk controller).  Get out those hardware diagnostics ...

            regards, tom lane