Re: ALTER DATABASE SET TABLESPACE vs crash safety - Mailing list pgsql-hackers

From Bernd Helmle
Subject Re: ALTER DATABASE SET TABLESPACE vs crash safety
Date
Msg-id 296AC2E59A3A173D31260BB8@imhotep.credativ.de
Whole thread Raw
In response to Re: ALTER DATABASE SET TABLESPACE vs crash safety  (Decibel! <decibel@decibel.org>)
List 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 by date:

Previous
From: "Ibrar Ahmed"
Date:
Subject: Re: pg_dump roles support [Review]
Next
From: ITAGAKI Takahiro
Date:
Subject: pg_do_encoding_conversion glitch