Re: pg_largeobject and tablespaces

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_largeobject and tablespaces
Date: 2004-06-24 10:38:36
Message-ID: Pine.LNX.4.58.0406242033080.29539@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 23 Jun 2004, Tom Lane wrote:

> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> > With our new tablespace set up, is it ever possible for someone to move
> > pg_largeobject to another tablespace?
>
> Assuming that ALTER TABLE SET TABLESPACE gets in, my preferred answer is
> to apply that operation to pg_largeobject.
>
> We do need to think a bit about what the safety constraints on ALTER
> TABLE SET TABLESPACE should be. To allow the above, we cannot
> completely forbid moving system catalogs. However, it will not work
> to allow moving *every* system catalog ... for instance, if you were to
> move pg_class itself, things would be more than slightly broken, because
> the backend could not find pg_class to learn where the system catalogs
> are.

Good point. I'm still yet to finish this patch as it was a little more
complex than I anticipated. At first, I added new entries to the queue for
ALTER TABLE in ATPrepCmd(). This didn't work because the toast and toast
index calls couldn't see themselves because they were droped when we
switch relfilenodes.

Then I realised that bad things happened if you changed the toast OIDs.
So, I'm going to work out a more elegant solution.

>
> It might be that we only need to forbid moving the "nailed" system
> relations, but I haven't thought it through yet.

Hmm.. that sounds okay.

Gavin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-06-24 11:00:59 Re: [PATCHES] Configuration patch
Previous Message Jeroen T. Vermeulen 2004-06-24 09:20:39 Re: PREPARE and transactions