Re: BUG #5384: pg_dump hard-codes use of /tmp

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jon Nelson" <jnelson(at)jamponi(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5384: pg_dump hard-codes use of /tmp
Date: 2010-03-19 20:13:40
Message-ID: 5574.1269029620@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Jon Nelson" <jnelson(at)jamponi(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Robert Haas 2010-03-20 00:26:29 Re: could not load library
Previous Message Tom Lane 2010-03-19 19:38:04 Re: segfault in pg 8.4, CurrentResourceOwner == NULL while processing SIGTERM