Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[BUGS] initdb must have write access to /tmp

0 views
Skip to first unread message

Rich Bodo

unread,
Oct 1, 2001, 12:24:36 PM10/1/01
to

Hi,

I was just installing postgres 7.1.2 on my linux mandrake 7.2
system and the build and install went fine up to the point I
had to run:

initdb -D /usr/local/pgsql/data

which segfaulted. I changed the permissions on /tmp to 777
and all was well. I think initdb could use an if statement to
check the permissions on /tmp and report a descriptive bug.

-Rich

Rich Bodo | r...@ostel.com | 650-964-4678


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)

Tom Lane

unread,
Oct 1, 2001, 6:21:53 PM10/1/01
to
Rich Bodo <r...@ostel.com> writes:
> I was just installing postgres 7.1.2 on my linux mandrake 7.2
> system and the build and install went fine up to the point I
> had to run:
> initdb -D /usr/local/pgsql/data
> which segfaulted. I changed the permissions on /tmp to 777
> and all was well. I think initdb could use an if statement to
> check the permissions on /tmp and report a descriptive bug.

I cannot replicate this in current sources; I get

creating directory /home/postgres/testversion/data... ok
creating directory /home/postgres/testversion/data/base... ok
creating directory /home/postgres/testversion/data/global... ok
creating directory /home/postgres/testversion/data/pg_xlog... ok
creating directory /home/postgres/testversion/data/pg_clog... ok
creating template1 database in /home/postgres/testversion/data/base/1... ok
creating configuration files... ok
initializing pg_shadow... /home/postgres/testversion/bin/initdb[505]: /tmp/sh4843.13: Cannot find or open the file.

initdb failed.
Removing /home/postgres/testversion/data.

which seems like reasonable behavior to me. On another machine I get
something about "Cannot create temp file for here document: Permission
denied".

My guess is that the core dump you are seeing is actually your shell's
fault, not Postgres'; probably the shell is not expecting a create of
its temp file to fail. If so, it would be inappropriate for us to put
in a test for /tmp writability, since that would be making an
unsupported assumption about where the local shell puts its internal
temp files.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org

0 new messages