Re: Using ALTER TABLESPACE in pg_dump

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using ALTER TABLESPACE in pg_dump
Date: 2004-10-25 03:29:28
Message-ID: 6.1.2.0.0.20041025131741.04783450@203.8.195.10
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 12:38 PM 25/10/2004, Bruce Momjian wrote:

> o Anything that works only for pg_restore and hence doesn't
> work for ASCII dumps isn't an acceptable solution

Agree; but don't forget that an ascii dump is implemented almost
identically to "pg_dump | pg_restore", so when I refer to using pg_restore
in this thread it almost certainly applies to ascii dumps as well. Eg.
extra stuff in the TOC, and using the definition as a template *will*
produce the requested output in ascii dumps.

> o Creating the tablespaces before the dump is restored is
> a good solution for moving tablespaces, but as Tom pointed
> out, it doesn't work well for non-super-user restores

And for users who want to create a single database with no extra
tablespaces (eg. development version vs. production instance).

> o Moving the indexes can't be dont easily after they are
> created because they are not zero-length files

Pity.

> o The soft-failure GUC option for non-existant tablespaces
> is a hack just for use by pg_dump. It doesn't fix the
> problem that the tablespace clause makes the SQL nonstandard.

If we can adopt the move-after-create solution, then we really only have
two options:

- virtual tablespaces (which do seem kind of useful, especially for
development vs. production config where the local/personal dev version
can use the same script as a production DB but not need half a dozen TSs)

- magic-tablespace-var that behaves like the schema search path

Are there any others?

>And the best quote from the thread:
>
>Philip Warner wrote:
> > <soapbox>
> > A fact I positively loath! Relying on the 'bluder-on-regardless' approach
> > is not something I'd like to enshrine.
> > </soapbox>
>
>The 'bluder-on-regardless' phrase is very funny.

Fame at last! Even with the typo.

----------------------------------------------------------------
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 |/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2004-10-25 04:59:46 Re: Proposed Query Planner TODO items
Previous Message Bruce Momjian 2004-10-25 02:44:54 Re: gettext calls in pgport