Re: Out of space

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Tom Bakken" <tom(dot)bakken(at)tx(dot)usda(dot)gov>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Out of space
Date: 2004-04-07 22:24:30
Message-ID: 5003.1081376670@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

"Tom Bakken" <tom(dot)bakken(at)tx(dot)usda(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Coby Beck 2004-04-07 23:41:15 parameter to control cycle detection
Previous Message Sam Barnett-Cormack 2004-04-07 22:23:17 Re: Query with Max, Order by is very slow.......