pgsql: Remove: * Allow database recovery where tablespaces can't be
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)
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, Pennsylvania 19073On 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, Pennsylvania 19073