Thread: "could not write to output file: Permission denied" during pg_dump

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.


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
> 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
>
>
>
>