Re: ALTER DATABASE SET TABLESPACE vs crash safety

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

In response to

Browse pgsql-hackers by date

  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]