"could not write to output file: Permission denied" during pg_dump
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. The table that
triggers the failure varies from run to run, and is not (or, so far has
not been) the first table processed. These failures only occur during
concurrent runs - we have not seen them when we single-thread the
pg_dump exports.
The command used to invoke pg_dump is as follows:
${currentCodeDir}/thirdPartyLinks/postgres/bin/pg_dump
--file=${currentDataDir}/${db_name}.dmp --format=custom
--host=${PostgreSQLServer} --port=${db_port} --username=xxxx
--no-privileges --verbose ${db_name}
Any ideas?
Michael Tefft
Snap-on Business Solutions
4025 Kinross Lakes Parkway
Richfield, OH 44286
330-659-1840
Michael.J.Tefft@snapon.com
Correction, that should have been Postgres 9.0.4 not 9.4.
Import Notes
Resolved by subject fallback
On 11/10/2012 06:19 AM, Tefft, Michael J wrote:
Correction, that should have been Postgres 9.0.4 not 9.4.
For some reason I did not get the original question. Found it in the
archives.
In that post you show the following:
The command used to invoke pg_dump is as follows:
${currentCodeDir}/thirdPartyLinks/postgres/bin/pg_dump
--file=${currentDataDir}/${db_name}.dmp --format=custom
--host=${PostgreSQLServer} --port=${db_port} --username=xxxx
--no-privileges --verbose ${db_name}
You say you are doing concurrent dumps of multiple databases.
Are talking different databases in different clusters or different
databases in a cluster?
If different databases in different clusters do they have the same name
in each cluster?
If so have you checked that: '--file=${currentDataDir}/${db_name}.dmp'
is not writing to the same file?
--
Adrian Klaver
adrian.klaver@gmail.com
"Tefft, Michael J" <Michael.J.Tefft@snapon.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
Sounds like a file sharing issue. In other words..writing to the same
file at the same time...from two separate pg_dump streams.
Perhaps adding a time var to the file name call below
and see if the error goes away.
Show quoted text
On Sat, 2012-11-10 at 08:03 -0600, Tefft, Michael J wrote:
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
deniedpg_dump: *** aborted because of error
This is after successfully dumping several tables. The table that
triggers the failure varies from run to run, and is not (or, so far
has not been) the first table processed. These failures only occur
during concurrent runs – we have not seen them when we single-thread
the pg_dump exports.The command used to invoke pg_dump is as follows:
${currentCodeDir}/thirdPartyLinks/postgres/bin/pg_dump --file=
${currentDataDir}/${db_name}.dmp --format=custom --host=
${PostgreSQLServer} --port=${db_port} --username=xxxx --no-privileges
--verbose ${db_name}Any ideas?
Michael Tefft
Snap-on Business Solutions
4025 Kinross Lakes Parkway
Richfield, OH 44286
330-659-1840
Michael.J.Tefft@snapon.com