From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Tefft, Michael J" <Michael(dot)J(dot)Tefft(at)snapon(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, "Jain, Ankit" <Ankit(dot)Jain(at)snapon(dot)com> |
Subject: | Re: "could not write to output file: Permission denied" during pg_dump |
Date: | 2012-11-10 15:27:16 |
Message-ID: | 9023.1352561236@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Tefft, Michael J" <Michael(dot)J(dot)Tefft(at)snapon(dot)com> writes:
> We have several Postgres 9.4 databases on Solaris 10 that are structural
> clones but with different data . While running multiple concurrent
> pg_dump exports for these databases, we get sporadic errors like this:
> pg_dump: dumping contents of table attachment
> pg_dump: [custom archiver] could not write to output file: Permission
> denied
> pg_dump: *** aborted because of error
> This is after successfully dumping several tables.
It's hard to see how that could be anything except an operating-system
bug. If we've been successfully writing on a file for awhile, there's
no way that another write should trigger a permission error. Unless
maybe they chose to report some sort of disk-quota-exceeded situation
as EPERM, but even so that choice seems wrong to me.
I'd suggest asking Sun^H^H^HOracle about this.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-11-10 16:37:31 | Re: control file errors |
Previous Message | Adrian Klaver | 2012-11-10 15:11:33 | Re: "could not write to output file: Permission denied" during pg_dump |