"initdb -t" destroys all databases

Richard Poole <richard.poole@vi.net> writes:

It seems that initdb starts a single-user backend but gives it the "-x"
option, which makes it call BootStrapXLOG, which fails because it
expects to be called only on absolutely first-time system startup (?).
initdb sees the failure and removes everything under the data directory,
which is the wrong behaviour here.

Sounds like a bug to me too. Peter E. has been hacking initdb to be
more robust; Peter, have you fixed this already in current sources?

regards, tom lane

Peter, comments?

Richard Poole <richard.poole@vi.net> writes:

It seems that initdb starts a single-user backend but gives it the "-x"
option, which makes it call BootStrapXLOG, which fails because it
expects to be called only on absolutely first-time system startup (?).
initdb sees the failure and removes everything under the data directory,
which is the wrong behaviour here.

Sounds like a bug to me too. Peter E. has been hacking initdb to be
more robust; Peter, have you fixed this already in current sources?

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian writes:

Peter, comments?

It doesn't destroy all databases anymore, although I can't make any
statements about what it actually does do. I suppose it's still broken.

Richard Poole <richard.poole@vi.net> writes:

It seems that initdb starts a single-user backend but gives it the "-x"
option, which makes it call BootStrapXLOG, which fails because it
expects to be called only on absolutely first-time system startup (?).
initdb sees the failure and removes everything under the data directory,
which is the wrong behaviour here.

Sounds like a bug to me too. Peter E. has been hacking initdb to be
more robust; Peter, have you fixed this already in current sources?

regards, tom lane

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Any idea if this is fixed?

Bruce Momjian writes:

Peter, comments?

It doesn't destroy all databases anymore, although I can't make any
statements about what it actually does do. I suppose it's still broken.

Richard Poole <richard.poole@vi.net> writes:

It seems that initdb starts a single-user backend but gives it the "-x"
option, which makes it call BootStrapXLOG, which fails because it
expects to be called only on absolutely first-time system startup (?).
initdb sees the failure and removes everything under the data directory,
which is the wrong behaviour here.

Sounds like a bug to me too. Peter E. has been hacking initdb to be
more robust; Peter, have you fixed this already in current sources?

regards, tom lane

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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

Any idea if this is fixed?

Peter, comments?

It doesn't destroy all databases anymore, although I can't make any
statements about what it actually does do. I suppose it's still broken.

Peter did put in a hack to make sure it wouldn't do "rm -rf $PGDATA"
upon failure, but it still doesn't appear to me to offer any non-broken
functionality. Note my comment in initdb.sh:

# XXX --- I do not believe the "template_only" option can actually work.
# With this coding, it'll fail to make entries for pg_shadow etc. in
# template1 ... tgl 11/2000

It occurs to me that the only likely use for initdb -t is now served by
DROP DATABASE template1;
CREATE DATABASE template1 WITH TEMPLATE = template0;
ie, we have a *real* way to reconstruct a virgin template1 rather than
an initdb kluge.

Accordingly, I suggest that initdb -t should be flushed entirely.
Comments?

regards, tom lane

Tom Lane writes:

It occurs to me that the only likely use for initdb -t is now served by
DROP DATABASE template1;
CREATE DATABASE template1 WITH TEMPLATE = template0;
ie, we have a *real* way to reconstruct a virgin template1 rather than
an initdb kluge.

I agree.

Accordingly, I suggest that initdb -t should be flushed entirely.

Kill it.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Tom Lane writes:

Accordingly, I suggest that initdb -t should be flushed entirely.

I guess we won't need two separate files global.bki and template1.bki
anymore. That would simplify some things, but maybe it's still a
stilistic thing.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

I guess we won't need two separate files global.bki and template1.bki
anymore. That would simplify some things, but maybe it's still a
stilistic thing.

It's probably not absolutely necessary to have two, but why change it?

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

I guess we won't need two separate files global.bki and template1.bki
anymore. That would simplify some things, but maybe it's still a
stilistic thing.

It's probably not absolutely necessary to have two, but why change it?

One less *bki file certainly would be cleaner. I never understood the
difference between them.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026