Thread

1. initdb and xpg_user

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-12T14:31:43Z

   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)
   
   

2. Re: [HACKERS] initdb and xpg_user

   Jan Wieck <jwieck@debis.com> — 1998-03-12T16:26:48Z

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

3. Re: [HACKERS] initdb and xpg_user

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-16T05:58:48Z

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