I looked in the pg_log file and it's missing xlogtemp.1091.:
[root@linux04 data]# tail pg_log
DEBUG: Redo record at (1, 516646732); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId: 28728439; NextOid: 9098648
FATAL 2: ZeroFill(/var/lib/pgsql/data/pg_xlog/xlogtemp.1033) failed: No
such file or directory
/usr/bin/postmaster: Startup proc 1033 exited with status 512 - abort
DEBUG: database system was shut down at 2004-04-07 12:14:38 CDT
DEBUG: CheckPoint record at (1, 516646732)
DEBUG: Redo record at (1, 516646732); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId: 28728439; NextOid: 9098648
FATAL 2: ZeroFill(/var/lib/pgsql/data/pg_xlog/xlogtemp.1091) failed: No
such file or directory
/usr/bin/postmaster: Startup proc 1091 exited with status 512 - abort
I'm sure I didn't delete it. Regardless, hopefully based on this one of you
might have a suggestion.
[root@linux04 data]#
Tom Bakken
Information Resource Manager
Texas USDA, Rural Development
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Wednesday, April 07, 2004 12:22 PM
To: Tom Bakken
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Out of space
"Tom Bakken" <tom.bakken@tx.usda.gov> writes:
> I've been running a postgres for 2 or 3 years without a problem. This
> morning my disk space for the database filled up. I need to know what
> transaction/log files I can truncate or delete without compromising the
> system. These files are located under /var/lib/pgsql/data/
I wouldn't recommend deleting *any* files manually --- unless you find
core files or old files underneath a pgsql_tmp subdirectory. Those you
could zap at little risk.
The best approach is to free up a small amount of space elsewhere,
enough so you can get through a CHECKPOINT without failing. The
checkpoint will hopefully free up some space in pg_xlog. After that you
can look at dropping tables you don't need any more, VACUUM FULL, etc.
regards, tom lane
