Thread: initdb and xpg_user

initdb and xpg_user

From
Bruce Momjian
Date:
I have a xpg_user file all my database directories.

Seems initdb is creating it.  Any way to prevent it from being created?

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Re: [HACKERS] initdb and xpg_user

From
jwieck@debis.com (Jan Wieck)
Date:
>
> I have a xpg_user file all my database directories.

    Hands off - this is my bug :-)

>
> Seems initdb is creating it.  Any way to prevent it from being created?
>

    Add a

    mv $PGDATA/base/template1/xpg_user $PGDATA/base/template1/pg_user

    after the UPDATE pg_class renaming xpg_user to pg_user in initdb.

    But this showed up another FEATURE! If you remove a tables file,
    the next time it is accessed it is recreated empty! I think this
    is not right, because after a system crash, a database file (I
    know, very unlikely) could reside in lost+found. It's IMHO not
    good to assume the table is empty and recreate the file silent.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

Re: [HACKERS] initdb and xpg_user

From
Bruce Momjian
Date:
>
> >
> > I have a xpg_user file all my database directories.
>
>     Hands off - this is my bug :-)
>
> >
> > Seems initdb is creating it.  Any way to prevent it from being created?
> >
>
>     Add a
>
>     mv $PGDATA/base/template1/xpg_user $PGDATA/base/template1/pg_user
>
>     after the UPDATE pg_class renaming xpg_user to pg_user in initdb.
>
>     But this showed up another FEATURE! If you remove a tables file,
>     the next time it is accessed it is recreated empty! I think this
>     is not right, because after a system crash, a database file (I
>     know, very unlikely) could reside in lost+found. It's IMHO not
>     good to assume the table is empty and recreate the file silent.
>

Patch applied.

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

*** ./bin/initdb/initdb.sh.orig    Mon Mar 16 00:55:12 1998
--- ./bin/initdb/initdb.sh    Mon Mar 16 00:57:25 1998
***************
*** 367,375 ****
--- 367,382 ----
          valuntil    abstime);" |\
      postgres -F -Q -D$PGDATA template1 2>&1 > /dev/null |\
      grep -v "'DEBUG:"
+
+ #move it into pg_user
  echo "UPDATE pg_class SET relname = 'pg_user' WHERE relname = 'xpg_user';" |\
      postgres -F -Q -D$PGDATA template1 2>&1 > /dev/null |\
      grep -v "'DEBUG:"
+ echo "UPDATE pg_type SET typname = 'pg_user' WHERE typname = 'xpg_user';" |\
+     postgres -F -Q -D$PGDATA template1 2>&1 > /dev/null |\
+     grep -v "'DEBUG:"
+ mv $PGDATA/base/template1/xpg_user $PGDATA/base/template1/pg_user
+
  echo "CREATE RULE _RETpg_user AS ON SELECT TO pg_user DO INSTEAD    \
          SELECT usename, usesysid, usecreatedb, usetrace,        \
                 usesuper, usecatupd, '********'::text as passwd,    \

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)