Re: ALTER DATABASE SET TABLESPACE vs crash safety

Поиск
Список
Период
Сортировка
От Bernd Helmle
Тема Re: ALTER DATABASE SET TABLESPACE vs crash safety
Дата
Msg-id 296AC2E59A3A173D31260BB8@imhotep.credativ.de
обсуждение исходный текст
Ответ на Re: ALTER DATABASE SET TABLESPACE vs crash safety  (Decibel! <decibel@decibel.org>)
Список pgsql-hackers
--On Sonntag, November 09, 2008 18:25:50 -0600 Decibel! 
<decibel@decibel.org> wrote:

> On Nov 7, 2008, at 9:53 AM, Tom Lane wrote:

> FWIW, I don't see this patch as being terribly useful in the real world
> until it can take place in the background, without locking stuff for a
> huge amount of time. That tells me that we should have a way to move
> objects to a new tablespace a little bit at a time. My guess is that such
> a facility would be something that runs in the background over many
> different transactions. Once everything had been moved, only then would
> it go and delete the old files.

Of course, such a facility is much more complicater than what this patch 
does. If you don't want to exclusive lock the database you need to track 
all changes during copying the relations and later merge them into the new 
ones in the worst case. I don't see how you want to preserve a consistent 
state of the database otherwise.

>
> But it's too late to get that kind of functionality into 8.4. :( So, is
> there enough demand for this feature to get it into 8.4 and possibly
> paint ourselves into a corner, or should we just wait until 8.5?

This patch is already committed.

--  Thanks
                   Bernd


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

Предыдущее
От: "Ibrar Ahmed"
Дата:
Сообщение: Re: pg_dump roles support [Review]
Следующее
От: ITAGAKI Takahiro
Дата:
Сообщение: pg_do_encoding_conversion glitch