Thread

  1. initdb -t trashes the entire database system

    PostgreSQL Bugs List <pgsql-bugs@postgresql.org> — 2000-08-29T19:06:51Z

    toby cabot (toby@caboteria.org) reports a bug with a severity of 1
    The lower the number the more severe it is.
    
    Short Description
    initdb -t trashes the entire database system
    
    Long Description
    Hi,
    
    PostgreSQL is very cool, kudos to all who have worked hard to make it
    so!
    
    initdb is pretty dangerous, though; it deleted my $PGDATA directory.
    
    I had a problem with my pgsql server (wouldn't start - something about
    log file corruption) so I was looking around in the docs for some way to
    truncate the log file (since the server was pretty quiet when it was
    shut down).  Anyway, I found "initdb -t" which looked like just the
    ticket, especially as the docs say "You can't destroy anything by
    running initdb with the --template option."
    
    On running initdb I got:
    
    
    [postgres@tiny pgsql]$ initdb -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 /usr/local/pgsql/data/base/template1
    FATAL 2:  BootStrapXLOG failed to create control file
    (/usr/local/pgsql/data/pg_control): 17
    FATAL 2:  BootStrapXLOG failed to create control file
    (/usr/local/pgsql/data/pg_control): 17
    /usr/local/pgsql/bin/initdb: line 443:  7462 Broken pipe             cat
    "$TEMPLATE"
          7463                       | sed -e
    "s/PGUID/$POSTGRES_SUPERUSERID/g"
          7464 Done(2)                 | "$PGPATH"/postgres $FIRSTRUN
    template1
    
    initdb failed.
    Removing /usr/local/pgsql/data.
    Removing temp file /tmp/initdb.7446.
    [postgres@tiny pgsql]$ 
    
    
    and I realize with some shock that initdb has just deleted my $PGDATA
    directory.  It does this because it tries to clean up after itself in
    case of errors.  My feeling is that things are pretty much in an
    undefined state after an error has occurred so the prudent thing to do
    is give the user as much info as possible and then bail out.  OTOH, I
    don't want to rock the boat so here's a patch to initdb that makes -n
    implicit in -t:
    
    
    --- bin/initdb.orig Fri Aug 11 22:12:10 2000
    +++ bin/initdb Fri Aug 11 22:33:59 2000
    @@ -157,6 +157,7 @@
                     ;;
             --template|-t)
                     template_only=1
    +                noclean=1    # don't trash existing data dir
                     echo "Updating template1 database only."
                     ;;
     # The sysid of the database superuser. Can be freely changed.
    
    
    With this patch it still fails but in a more graceful way.
    
    If anyone has any insight into why it -t fails that would be much
    appreciated, too.
    
    Regards,
    Toby Cabot
    
    Sample Code
    
    
    No file was uploaded with this report