Thread: "initdb -t" destroys all databases
No response to this one on -general, so here goes... The documentation for initdb says that the "-t" (== "--template") option recreates the template1 database but doesn't touch anything else. But it seems that if it detects a failure it will abort and remove anything it *might* have created: -- begin cut-and-paste [barbra rp]/usr/lib/postgresql/bin/initdb -t -D /home/rp/tmp/pgtest Updating template1 database only. This database system will be initialized with username "rp". This user will own all the data files and must also own the server process. Creating template database in /home/rp/tmp/pgtest/base/template1 000925.16:49:28.545 [5432] FATAL 2: BootStrapXLOG failed to create control file (/home/rp/tmp/pgtest/pg_control): 17 000925.16:49:28.545 [5432] FATAL 2: BootStrapXLOG failed to create control file (/home/rp/tmp/pgtest/pg_control): 17 initdb failed. Removing /home/rp/tmp/pgtest. Removing temp file /tmp/initdb.5412. -- end cut-and-paste 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. Everything seems to be OK if I fix initdb not to pass "-x" to postgres if it's been given "-t", but I don't know enough to know that this is really the right thing. If it is, I'll submit a patch; any opinions? Richard
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, Pennsylvania19026
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, Pennsylvania19026
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 byDROP DATABASE template1;CREATE DATABASE
template1WITH 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, Pennsylvania19026