TODO item removed:

* 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.

Not done yet, but it will be with SET default_tablespace.

I don't think we need "adjust" but rather default to the default
tablespace is just fine, and they can pre-create tablespaces in
different locations to adjust the restore anyway.

Great!

---------------------------------------------------------------------------

Philip Warner wrote:
At 06:19 AM 6/11/2004, Tom Lane wrote:
You had muttered something about wanting to add
a TOC entry field for this --- do you still want to do the work?
You can probably get it done faster than I could, but I dunno if you
have time at the moment. I'd like to get it in over the weekend so
that we can put out a new beta next week.
Time is at a serious premium for me at the moment (I have several projects
all due about now); but I wrote a patch for this a few weeks back, so it
should not be a lot of work (unless pg_dump has changed in the last couple
of months).

I will *try* to get it done by Monday morning your time, and will let you
know if I am going to miss this deadline as soon as I know.

BTW, part of the backend changes was to stop emitting TABLESPACE
clauses in pg_get_indexdef() and pg_get_constraintdef() output,
so as of CVS tip pg_dump will in fact fail to restore index tablespaces
accurately. I assume this is the backend behavior you want, but
holler if not.
Excellent. I assume that anything that can have a tablespace (database,
schema(?), table and index -- anything else?) should emit a 'set
default_tablespace="ts"' before creation (and that this will affect
auto-created indexes as appropriate, whatever that means).

Thanks for all the work.



----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
--________--
PGP key available upon request, | /
and from pgp.mit.edu:11371 |/


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
--
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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 43 of 45 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedOct 18, '04 at 4:27p
activeNov 6, '04 at 7:37p
posts45
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase