"initdb -t" ate my baby - Mailing list pgsql-general

From Richard Poole
Subject "initdb -t" ate my baby
Date
Msg-id 20000911182753.B20570@office.vi.net
Whole thread Raw
List pgsql-general
I've found what may be a bug in initdb, a bug in its documentation, a
misunderstanding on my part, or a combination of the above. I'm using
7.0.2 under Debian GNU/Linux. The User's Guide says of the "-t" or
"--template" option:

> Replace the template1 database in an existing database system, and don't
> touch anything else.

[...]

> You can't destroy anything by running initdb with the --template option.


But when I try it:

barbra:/home/rp$ /usr/lib/postgresql/bin/initdb -D /var/lib/postgres/data -t
Updating template1 database only.
This database system will be initialized with username "postgres".
This user will own all the data files and must also own the server process.

Creating template database in /var/lib/postgres/data/base/template1
000911.16:55:00.054  [2376] FATAL 2:  BootStrapXLOG failed to create control file (/var/lib/postgres/data/pg_control):
17
000911.16:55:00.054  [2376] FATAL 2:  BootStrapXLOG failed to create control file (/var/lib/postgres/data/pg_control):
17

initdb failed.
Removing /var/lib/postgres/data.
Removing temp file /tmp/initdb.2356.


Oh dear. My whole data directory has been blown away. What seems to be
happening is that initdb removes the existing template1, then calls
the "postgres" bootstrap backend, which tries to create the whole data
directory from scratch, although most of it is still there. It fails and
aborts with the two FATAL errors above. initdb notices that it has
failed and goes to its cleanup function, "exit_nicely", which removes
any directories that initdb *might* have created, including my data
directory.

There seem to be two separate problems here:

1) initdb invokes the postgres backend in the wrong way for the purpose
when the "-t" option is given.

2) the cleanup function doesn't know about the "-t" option, so it
removes things that in this particular case it shouldn't.


The second is easy to fix with a quick patch. The first is beyond my
knowledge of the internals. But as I've never seen anyone else mention
this problem, I suspect I've just completely misunderstood something.
Would anyone care to comment?


Richard

pgsql-general by date:

Previous
From: "Darrin Ladd"
Date:
Subject: Re: Re: Race conditions...
Next
From: "Darrin Ladd"
Date:
Subject: Re: Removing all NOT NULL constraints from multiple tables easily