Tom - thanks for explaining the space issue. I think I have that now and yes, we do need more space. However, you seem to be misunderstanding my issue with the return codes. Whether I run this job as postgres or as root (with the 'su' command), the job fails with the message :
pg_dump: [tar archiver] could not write to tar member (wrote 158, attempted 285)
With the 'su', zero is returned and with postgres running the job, one is returned. How can this be? Is this perhaps an su issue and not a pg_dump issue?
Tom Lane wrote:
Derek Main <djm@ct.ucs.co.za> writes:
[ pg_dump works as root, fails as postgres ]
I have since found that this is not caused by a space problem since the
last time I ran the command, only 90% of the disk was used when it
crashed.
I think you've forgotten a standard Unix behavior: root is allowed to
use up every last block of disk space, but ordinary unprivileged users
aren't. Ordinary processes will typically start getting "out of disk
space" errors at either 90% or 95% full, depending on what your minfree
setting is for the particular filesystem.
Reducing minfree to zero is *not* a good idea, because filesystem
performance goes to hell in a handbasket when you are down to very
small amounts of free space. It's time to buy a bigger disk, or do
some housekeeping to free up space.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org