Tom,
I'm not sure how to check about the postgres user disk space limit issue. I
tried storing a rather large file on the postgres partition as the postgres
user and had no problem. I'm more suspicious of the file stored in:
[root@linux04 data]# ls -l /var/lib/pgsql/data/pg_xlog/
total 16404
-rw------- 1 postgres postgres 16777216 Apr 7 12:14 000000010000001E
Is it typical? It doesn't look it.
Anyway, I've got plenty of space but am unsure of the next step.
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 5:25 PM
To: Tom Bakken
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Out of space
"Tom Bakken" <tom.bakken@tx.usda.gov> writes:
> OK, it's truncated and now I've got plenty of space, but it's still
> complaining that it can't find the xlogtemp.1405:
> FATAL 2: ZeroFill(/var/lib/pgsql/data/pg_xlog/xlogtemp.1405) failed: No
> such file or directory
I think the "no such file" errno is probably actively misleading. I
took another look at the CVS logs and realized that in 7.1.2, there is
no guarantee that that message actually reflects the cause of the write
failure --- if write() indicates it couldn't write all the bytes, but
does not set errno, then the reported errno will be left over from the
last failed operation. We had patched this by 7.1.3, which is the
version I was looking at locally. Since ENOENT can't be returned by
write() AFAIK, it seems certain that this is indeed a leftover errno
setting.
In short, I still think you are running into some kind of
out-of-disk-space failure. I'm not sure what, but you might look to
whether you've exceeded the postgres user's disk space quota, or
anything along that line. Keep in mind also that an unprivileged user
account normally can't fill the disk as full as root can.
regards, tom lane