Thread: Re: [COMMITTERS] pgsql: Remove: * Allow database recovery where
Just curious, but in what sort of circumstance could this happen? Permissions problems, that sort of thing? On Sat, 6 Nov 2004, Bruce Momjian wrote: > Log Message: > ----------- > Remove: > > * Allow database recovery where tablespaces can't be created > > When a pg_dump is restored, all tablespaces will attempt to be created > in their original locations. If this fails, the user must be able to > adjust the restore process. > > Modified Files: > -------------- > pgsql/doc: > TODO (r1.1385 -> r1.1386) > (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1385&r2=1.1386) > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > > Just curious, but in what sort of circumstance could this happen? > Permissions problems, that sort of thing? Restoring a dump to another system that doesn't have the same directories to create the tablespaces. --------------------------------------------------------------------------- > > On Sat, 6 Nov 2004, Bruce Momjian wrote: > > > Log Message: > > ----------- > > Remove: > > > > * Allow database recovery where tablespaces can't be created > > > > When a pg_dump is restored, all tablespaces will attempt to be created > > in their original locations. If this fails, the user must be able to > > adjust the restore process. > > > > Modified Files: > > -------------- > > pgsql/doc: > > TODO (r1.1385 -> r1.1386) > > (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1385&r2=1.1386) > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Mon, 8 Nov 2004, Bruce Momjian wrote: > Marc G. Fournier wrote: >> >> Just curious, but in what sort of circumstance could this happen? >> Permissions problems, that sort of thing? > > Restoring a dump to another system that doesn't have the same > directories to create the tablespaces. 'k, that's what I thought, just wanted to clarify ... stupid question then ... if such a case happens, do we send a WARNING to let ppl know that the load didn't quite go as the dump went? > > --------------------------------------------------------------------------- > >> >> On Sat, 6 Nov 2004, Bruce Momjian wrote: >> >>> Log Message: >>> ----------- >>> Remove: >>> >>> * Allow database recovery where tablespaces can't be created >>> >>> When a pg_dump is restored, all tablespaces will attempt to be created >>> in their original locations. If this fails, the user must be able to >>> adjust the restore process. >>> >>> Modified Files: >>> -------------- >>> pgsql/doc: >>> TODO (r1.1385 -> r1.1386) >>> (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1385&r2=1.1386) >>> >>> ---------------------------(end of broadcast)--------------------------- >>> TIP 4: Don't 'kill -9' the postmaster >>> >> >> ---- >> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) >> Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 3: if posting/reading through Usenet, please send an appropriate >> subscribe-nomail command to majordomo@postgresql.org so that your >> message can get through to the mailing list cleanly >> > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Mon, 8 Nov 2004, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > >> > >> Just curious, but in what sort of circumstance could this happen? > >> Permissions problems, that sort of thing? > > > > Restoring a dump to another system that doesn't have the same > > directories to create the tablespaces. > > 'k, that's what I thought, just wanted to clarify ... stupid question then > ... if such a case happens, do we send a WARNING to let ppl know that the > load didn't quite go as the dump went? Yes, they get a warning because the tablespace create failed. When we had a TABLESPACE clause in create (before default_tablespace), all the CREATEs would fail leading to a useless restore. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073