[HACKERS] pg_largeobject and tablespaces
With our new tablespace set up, is it ever possible for someone to move pg_largeobject to another tablespace? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_largeobject and tablespaces
Christopher Kings-Lynne <[EMAIL PROTECTED]> 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. It might be that we only need to forbid moving the "nailed" system relations, but I haven't thought it through yet. If nothing else comes to mind, a reasonable compromise for 7.5 would be to forbid moving any system catalog except pg_largeobject and its indexes ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_largeobject and tablespaces
If nothing else comes to mind, a reasonable compromise for 7.5 would be to forbid moving any system catalog except pg_largeobject and its indexes ... Plus pg_dump support for it :/ Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_largeobject and tablespaces
On Wed, 23 Jun 2004, Tom Lane wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_largeobject and tablespaces
I have added to TODO: * Allow moving system tables to other tablespaces, where possible --- Tom Lane wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> 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. > > It might be that we only need to forbid moving the "nailed" system > relations, but I haven't thought it through yet. > > If nothing else comes to mind, a reasonable compromise for 7.5 would be > to forbid moving any system catalog except pg_largeobject and its > indexes ... > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
