Skip site navigation (1) Skip section navigation (2)

Re: patch : Allow toast tables to be moved to a different tablespace

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Julien Tachoires <julmon(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch : Allow toast tables to be moved to a different tablespace
Date: 2011-12-15 13:37:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Excerpts from Julien Tachoires's message of mar dic 13 14:29:56 -0300 2011:
> 2011/12/13 Robert Haas <robertmhaas(at)gmail(dot)com>:
> > On Tue, Dec 13, 2011 at 12:02 PM, Julien Tachoires <julmon(at)gmail(dot)com> wrote:
> >> Right, it seems to happen when the destination tablespace is the same
> >> as the database's tbs, because, in this case, relation's tbs is set to
> >> InvalidOid :
> >> src/backend/commands/tablecmds.c line 8342
> >>
> >> +       rd_rel->reltablespace = (newTableSpace == MyDatabaseTableSpace) ?
> >> InvalidOid : newTableSpace;
> >>
> >> Why don't just asign newTableSpace value here ?
> >
> > When a relation is stored in the default tablespace, we always record
> > that in the system catalogs as InvalidOid.  Otherwise, if the
> > database's default tablespace were changed, things would break.
> OK, considering that, I don't see any way to handle the case raised by Jaime :(

Uhm, surely you could compare the original toast tablespace to the heap
tablespace, and if they differ, handle appropriately when creating the
new toast table?  Just pass down the toast tablespace into
AlterTableCreateToastTable, instead of having it assume that
rel->rd_rel->relnamespace is sufficient.  This should be done in all
cases where a toast tablespace is created, which shouldn't be more than
a handful of them.

Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-12-15 13:51:33
Subject: Moving more work outside WALInsertLock
Previous:From: 高增琦Date: 2011-12-15 13:30:56
Subject: why do we need create tuplestore for each fetch?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group