Re: BUG #5384: pg_dump hard-codes use of /tmp - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5384: pg_dump hard-codes use of /tmp
Date
Msg-id 5574.1269029620@sss.pgh.pa.us
Whole thread Raw
In response to BUG #5384: pg_dump hard-codes use of /tmp  ("Jon Nelson" <jnelson@jamponi.net>)
List pgsql-bugs
"Jon Nelson" <jnelson@jamponi.net> writes:
> I was trying to dump a database (with --format=tar).

Do you have a really good reason to be using tar rather than custom
format?  If so what is it?

> 1. why is pg_dump using a temporary directory (other than the $CWD) anyway?

Tar format is sufficiently weird that we have to dump data into a temp
file and then append it to the archive after we know its exact size.
This means double copying of data, as well as problems if your temp
directory is in an undersized filesystem.  On the whole, custom format
is a lot better bet from a performance standpoint --- so we only
recommend tar format if you have a clear need to be able to disassemble
the archive with non-Postgres tools.

> 2. More importantly, why is pg_dump ignoring TMPDIR ?

The temp files are created with the standard library function tmpfile().
If you think that's behaving improperly, take it up with your OS vendor.
I suspect they'll tell you it would be a security risk for that function
to respond to environment variables.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: segfault in pg 8.4, CurrentResourceOwner == NULL while processing SIGTERM
Next
From: Robert Haas
Date:
Subject: Re: could not load library