Re: Tablespace patch review

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Tablespace patch review
Дата
Msg-id 200406180456.i5I4uEo16721@candle.pha.pa.us
обсуждение исходный текст
Ответ на Tablespace patch review  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Tablespace patch review  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: Tablespace patch review  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-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@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

В списке pgsql-patches по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: nested xacts and phantom Xids
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: Tablespace patch review