Thread

initdb --sysid does not work

Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-23T21:46:13Z

In 7.1 and current sources, trying to use initdb's --sysid option to set
the postgres superuser's sysid does not work correctly.  pg_shadow is
set up with the correct username and usesysid, but about half of the
standard system objects are nonetheless created with the postgres user's
Unix sysid.  Example:

$ id
uid=256(postgres) gid=20(users)
$ initdb -i 333
This database system will be initialized with username "postgres".
... etc etc ...
$ start postmaster...
$ psql template1
template1=# create user uid_256 with sysid 256;
CREATE USER
template1=# select * from pg_shadow;
 usename  | usesysid | usecreatedb | usetrace | usesuper | usecatupd | passwd |
valuntil
----------+----------+-------------+----------+----------+-----------+--------+-
---------
 postgres |      333 | t           | t        | t        | t         |        |
 uid_256  |      256 | f           | f        | f        | f         |        |
(2 rows)

template1=# \dS
          List of relations
      Name      |  Type   |  Owner
----------------+---------+----------
 pg_aggregate   | table   | uid_256
 pg_am          | table   | uid_256
 pg_amop        | table   | uid_256
 pg_amproc      | table   | uid_256
 pg_attrdef     | table   | postgres
 pg_attribute   | table   | postgres
 pg_class       | table   | postgres
 pg_database    | table   | postgres
 pg_description | table   | uid_256
 pg_group       | table   | postgres
 pg_index       | table   | uid_256
 pg_indexes     | view    | postgres
 pg_inherits    | table   | uid_256
 pg_language    | table   | uid_256
 pg_largeobject | table   | uid_256
 pg_listener    | table   | uid_256
 etc

It looks to me like the ones that are the unwanted userid are the ones
that are created by "create" bootstrap commands (as opposed to being
forcibly inserted into the various tables after substitution of PGUID).
Probably, the bootstrap backend is using the result of geteuid() with
no idea that initdb thinks something different should happen.

This is breaking the Debian package, or at least causing it to behave
undesirably.

			regards, tom lane