From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
---|---|
To: | Decibel! <decibel(at)decibel(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
Subject: | Re: ALTER DATABASE SET TABLESPACE vs crash safety |
Date: | 2008-11-10 10:51:48 |
Message-ID: | 296AC2E59A3A173D31260BB8@imhotep.credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
--On Sonntag, November 09, 2008 18:25:50 -0600 Decibel!
<decibel(at)decibel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | ITAGAKI Takahiro | 2008-11-10 11:23:23 | pg_do_encoding_conversion glitch |
Previous Message | Ibrar Ahmed | 2008-11-10 10:48:36 | Re: pg_dump roles support [Review] |