8.0: Absolute path required for INITDB?

Josh Berkus <josh@agliodbs.com> writes:

If a relative path is used for the -L option in initdb, the following fatal
error happens:

7.4 fails in the same way, and probably every prior release too.
The problem is that the backend has done a chdir into the template1
subdirectory, so paths that are relative from your perspective
no longer apply.

It might be worth absolut-izing this path in initdb before it's
passed down, but I can't get exceedingly excited about it.

regards, tom lane

Tom,

It might be worth absolut-izing this path in initdb before it's
passed down, but I can't get exceedingly excited about it.

Well, once again let me check the docs to make sure people are warned about
this ....

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh@agliodbs.com> writes:

It might be worth absolut-izing this path in initdb before it's
passed down, but I can't get exceedingly excited about it.

Well, once again let me check the docs to make sure people are warned about
this ....

Why would it matter? I don't think I've ever once had occasion to use
the -L switch in initdb, because it figures it out just fine for itself.
People who are using it should be wizardly enough to know about the
chdir.

regards, tom lane

Tom,

Why would it matter? I don't think I've ever once had occasion to use
the -L switch in initdb, because it figures it out just fine for itself.
People who are using it should be wizardly enough to know about the
chdir.

Oh. Then I have a different bug to report, because INITDB for Sunday's CVS
would not run without the -L option.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh@agliodbs.com> writes:

Oh. Then I have a different bug to report, because INITDB for Sunday's CVS
would not run without the -L option.

Well, that does deserve investigation. But I've been initdb'ing
frequently and not noticed any problems. What configure switches
did you use exactly? Did you try to move the installation tree
after configure?

regards, tom lane

Tom,

Well, that does deserve investigation. But I've been initdb'ing
frequently and not noticed any problems. What configure switches
did you use exactly? Did you try to move the installation tree
after configure?

My only configure switch was --prefix=/usr/local/pg80b

I did not move the tree.

I will drop the data directory and re-run it so I can cut and paste the error
this afternoon.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Tom,

Well, that does deserve investigation. But I've been initdb'ing
frequently and not noticed any problems. What configure switches
did you use exactly? Did you try to move the installation tree
after configure?

Here's the issue: if you start initdb from a directory other than PGBASE, you
can run into trouble:

postgres@mole:/usr/local/pg80b/bin> ./initdb -D ../data
initdb: file "/usr/local/pg80b/bin/share/postgresql/postgres.bki" does not
exist
This means you have a corrupted installation or identified
the wrong directory with the invocation option -L.
postgres@mole:/usr/local/pg80b/bin>

I don't recall having this issue with 7.4.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

hi,

Josh Berkus wrote, On 8/9/2004 21:20:

Tom,

Well, that does deserve investigation. But I've been initdb'ing
frequently and not noticed any problems. What configure switches
did you use exactly? Did you try to move the installation tree
after configure?

Here's the issue: if you start initdb from a directory other than PGBASE, you
can run into trouble:

postgres@mole:/usr/local/pg80b/bin> ./initdb -D ../data
initdb: file "/usr/local/pg80b/bin/share/postgresql/postgres.bki" does not
exist
This means you have a corrupted installation or identified
the wrong directory with the invocation option -L.
postgres@mole:/usr/local/pg80b/bin>

same problem here, but I did a trick, changed the $libdir in
share/conversion_create.sql to full path to lib dir, and I did a symlink
in bin to share.

C.

Josh Berkus <josh@agliodbs.com> writes:

Here's the issue: if you start initdb from a directory other than PGBASE, you
can run into trouble:

postgres@mole:/usr/local/pg80b/bin> ./initdb -D ../data
initdb: file "/usr/local/pg80b/bin/share/postgresql/postgres.bki" does not
exist

Actually, the problem seems to be specific to the use of "." or ".." in
the invocation path. I have applied a patch that seems to fix it for
me.

I don't recall having this issue with 7.4.

All that path-hacking logic is new in 8.0, I believe. Before we were
using some shell utilities to do it for us.

regards, tom lane

Why don't we just throw an error if it isn't an abolute path name,
rather than failing in a weird way?

---------------------------------------------------------------------------

Josh Berkus wrote:

Tom,

Well, that does deserve investigation. But I've been initdb'ing
frequently and not noticed any problems. What configure switches
did you use exactly? Did you try to move the installation tree
after configure?

Here's the issue: if you start initdb from a directory other than PGBASE, you
can run into trouble:

postgres@mole:/usr/local/pg80b/bin> ./initdb -D ../data
initdb: file "/usr/local/pg80b/bin/share/postgresql/postgres.bki" does not
exist
This means you have a corrupted installation or identified
the wrong directory with the invocation option -L.
postgres@mole:/usr/local/pg80b/bin>

I don't recall having this issue with 7.4.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

What was the resolution of this? Can we make relative -L work or do we
add error checks for relative -L paths?

---------------------------------------------------------------------------

Josh Berkus wrote:

8.0 beta CVS of 8/8/2004:

If a relative path is used for the -L option in initdb, the following fatal
error happens:

./initdb -D ../data -L ../share/postgresql/
<snip>
creating system views ... ok
loading pg_description ... ERROR: could not open file
"../share/postgresql/postgres.description" for reading: No such file or
directory
child process exited with exit code 1

Is this intentional? The first dozen or so commands work fine with a relative
path, and this executes fine with an absolute path for both -D and -L.

SuSE 9.1, GCC 3.3.3

--
Josh Berkus
Aglio Database Solutions
San Francisco

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

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

What was the resolution of this? Can we make relative -L work or do we
add error checks for relative -L paths?

We fixed the problem that was requiring Josh to use -L. I think -L is a
wizard's switch and need not be user-friendly, so I feel no need to do
either of the above.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

What was the resolution of this? Can we make relative -L work or do we
add error checks for relative -L paths?

We fixed the problem that was requiring Josh to use -L. I think -L is a
wizard's switch and need not be user-friendly, so I feel no need to do
either of the above.

Yea, but it is so easy to fix, so why not do it. Patch attached.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Patch to throw an error if -L is not an abolute path attached and
applied.

---------------------------------------------------------------------------

Josh Berkus wrote:

8.0 beta CVS of 8/8/2004:

If a relative path is used for the -L option in initdb, the following fatal
error happens:

./initdb -D ../data -L ../share/postgresql/
<snip>
creating system views ... ok
loading pg_description ... ERROR: could not open file
"../share/postgresql/postgres.description" for reading: No such file or
directory
child process exited with exit code 1

Is this intentional? The first dozen or so commands work fine with a relative
path, and this executes fine with an absolute path for both -D and -L.

SuSE 9.1, GCC 3.3.3

--
Josh Berkus
Aglio Database Solutions
San Francisco

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

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Patch to throw an error if -L is not an abolute path attached and
applied.

Why are we placing this restriction? What Josh tried to do seems
perfectly reasonable to me. Rather I would ask why we changed the
description-loading routine in version 1.7 of initdb.c to use a copy
from file instead of what happens everywhere else where initdb loads the
file and feeds it to the postgres stdin? And if we want to keep doing
that rather than being consistent with the rest of initdb, can't we just
make sure we make the path absolute?

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Rather I would ask why we changed the
description-loading routine in version 1.7 of initdb.c to use a copy
from file instead of what happens everywhere else where initdb loads the
file and feeds it to the postgres stdin?

That was to avoid a Windows-only newline problem. Don't complain too
hard.

You are in any case missing the point: -L is a useless switch and there
is no reason to make it easy to use. (I don't think I have ever once
had occasion to use it in all the years I've worked on Postgres, and I
have certainly run initdb in orders-of-magnitude more contexts than any
ordinary user would.) If I have to waste any more time on this
discussion, I will propose solving the problem by removing the switch
entirely.

regards, tom lane

Andrew Dunstan wrote:

Bruce Momjian wrote:

Patch to throw an error if -L is not an abolute path attached and
applied.

Why are we placing this restriction? What Josh tried to do seems
perfectly reasonable to me. Rather I would ask why we changed the
description-loading routine in version 1.7 of initdb.c to use a copy
from file instead of what happens everywhere else where initdb loads the
file and feeds it to the postgres stdin? And if we want to keep doing
that rather than being consistent with the rest of initdb, can't we just
make sure we make the path absolute?

I am fine with that if someone wants to code it. I just did the minimal
to prevent strange failures.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Rather I would ask why we changed the
description-loading routine in version 1.7 of initdb.c to use a copy
from file instead of what happens everywhere else where initdb loads the
file and feeds it to the postgres stdin?

That was to avoid a Windows-only newline problem. Don't complain too
hard.

Well, I've tried to fix every newline problem I've come across - I
wasn't aware of this one.

You are in any case missing the point: -L is a useless switch and there
is no reason to make it easy to use. (I don't think I have ever once
had occasion to use it in all the years I've worked on Postgres, and I
have certainly run initdb in orders-of-magnitude more contexts than any
ordinary user would.) If I have to waste any more time on this
discussion, I will propose solving the problem by removing the switch
entirely.

Sorry - I don't read -bugs so I haven't followed the discussion.

Removing it makes more sense to me, frankly.

cheers

andrew