Problem with initdb -W

I have an IRC report, confirmed, that in RC2 initdb -W (set super-user
password) fails:

Enter new superuser password:
Enter it again:
setting password...
The group file wasn't generated. Please report this problem.

initdb failed.
Removing /u/pg/data.

I had actually experienced this problem as well on a one-off test machine.
However I just put it down to weirdness and didn't follow it up...sorry...

Chris

It was easier than I thought. As I now remember, it is not a problem if
pg_pwd or pg_group don't exist. Initdb should check for pg_pwd because
it just added a password, so it better exist, but there is no reason for
pg_group to exist at this point.

I will patch 7.3 and current CVS. I don't think this warrants another
RC candidate. This is the type of cleanup we will be doing to the 7.3
branch for the next few months anyway as part of minor releases.

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

Bruce Momjian wrote:

I have an IRC report, confirmed, that in RC2 initdb -W (set super-user
password) fails:

$ initdb -W
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /u/pg/data... ok
creating directory /u/pg/data/base... ok
creating directory /u/pg/data/global... ok
creating directory /u/pg/data/pg_xlog... ok
creating directory /u/pg/data/pg_clog... ok
creating template1 database in /u/pg/data/base/1... ok
creating configuration files... ok
initializing pg_shadow... ok
Enter new superuser password:
Enter it again:
setting password...
The group file wasn't generated. Please report this problem.

initdb failed.
Removing /u/pg/data.

Of course, the obvious solution is not to use -W. ;-)

I will research this but I wanted to report it right away. My only
guess is that the standalone backend to alter the super-user password is
messing up things:

"$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null <<EOF
ALTER USER "$POSTGRES_SUPERUSERNAME" WITH PASSWORD '$FirstPw';

-- 
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

---------------------------(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

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

It was easier than I thought. As I now remember, it is not a problem if
pg_pwd or pg_group don't exist. Initdb should check for pg_pwd because
it just added a password, so it better exist, but there is no reason for
pg_group to exist at this point.

I think I may have induced this problem during this change:

Revision 1.113 / (download) - annotate - [select for diffs] , Mon Oct 21 19:46:45 2002 UTC (5 weeks ago) by tgl
CVS Tags: REL7_3_STABLE, HEAD
Changes since 1.112: +144 -67 lines
Diff to previous 1.112

Make CREATE/ALTER/DROP USER/GROUP transaction-safe, or at least pretty
nearly so, by postponing write of flat password file until transaction
commit.

I modified user.c to keep track separately of pg_shadow and pg_group
changes, so that it would write only the file it needed to. Before
that, it probably *was* true that the initial assignment of a password
to the superuser would cause both pg_pwd and an empty pg_group to be
created. Too bad it didn't occur to me to test initdb -W :-(

I will patch 7.3 and current CVS. I don't think this warrants another
RC candidate.

Agreed, removal of an incorrect error check seems pretty safe ...

regards, tom lane