Skip site navigation (1) Skip section navigation (2)

Re: Tablespace patch review

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Subject: Re: Tablespace patch review
Date: 2004-06-18 04:56:14
Message-ID: 200406180456.i5I4uEo16721@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Bruce Momjian wrote:
> Gavin Sherry wrote:
> > Attached is an updated patch, fixing a compile error which my compiler
> > didn't seem to detect/suffer from and incorporating fixes to problems
> > raised by Neil.
> > 
> > Thanks,
> > 
> > Gavin
> 
> OK, I have reviewed the patch.  I think Tom is doing the same, but I
> want to report the things I found.

I have a few other questions:

What is the procedure for moving tablespace directories?  I assume with
the postmaster down the directory can be moved and the symlink changed. 
However, pg_tablespace still has the old location.  Should we use lstat
so pg_tablespace gets updated automatically or as part of pg_dump, or
throw a server message if the symlink doesn't match pg_tablespace.  We
need to add instructions that pg_tablespace needs to be updated if the
symlink is changed.  What bothers me is that someone updating just the
symlink might run fine but would not be able to restore a dump to the
same machine.

And about restore, particularly to another machine, what do we do if the
tablespace can't be created in the location specified in the dump?  The
tablespace creation fails, and all objects specified in that tablespace
also fail?  Seems bad, particularly if you are restoring after a
hardware failure.  Do we need a GUC that says "if the tablespace doesn't
exist, create the object in the default location?"   Do we need a
pg_dump option that ignores tablespaces completely for portability and
for restoring to another server?

Is pg_dump smart enough not to emit the tablespace if the object would
already be created in the right tablespace, perhaps because of its
schema?  The new tablespace clause adds a non-standard clause to CREATE
TABLE, something we were hoping to avoid, but I doubt it is possible.

Do we need ALTER TABLESPACE to move tablespaces, and ALTER clauses to
move objects to other tablespaces?  Are these TODO items for later?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2004-06-18 05:35:06
Subject: Re: Tablespace patch review
Previous:From: Tom AllisonDate: 2004-06-18 02:47:01
Subject: Re: [GENERAL] SCO embraces MySQL

pgsql-patches by date

Next:From: Christopher Kings-LynneDate: 2004-06-18 05:35:06
Subject: Re: Tablespace patch review
Previous:From: Barry LindDate: 2004-06-18 02:13:02
Subject: Re: Nested transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group