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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #5384: pg_dump hard-codes use of /tmp
Дата
Msg-id 5574.1269029620@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #5384: pg_dump hard-codes use of /tmp  ("Jon Nelson" <jnelson@jamponi.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: segfault in pg 8.4, CurrentResourceOwner == NULL while processing SIGTERM
Следующее
От: Robert Haas
Дата:
Сообщение: Re: could not load library