Re: [PATCHES] ALTER TABLE ... SET TABLESPACE - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Date
Msg-id Pine.LNX.4.58.0406211319220.26268@linuxworld.com.au
Whole thread Raw
In response to Re: [PATCHES] ALTER TABLE ... SET TABLESPACE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
List pgsql-hackers
On Sun, 20 Jun 2004, Tom Lane wrote:

> Gavin Sherry <swm@linuxworld.com.au> writes:
> > But I did implement it as a tuple at a time thing. I reused the code from
> > rebuild_relation()...
>
> > What did you have in mind?
>
> Something about like
>
>     for (b = 0; b < RelationGetNumberOfBlocks(src); b++)
>     {
>         smgrread(src, b, buf);
>         smgrwrite(dst, b, buf);
>     }
>
> Given that the only files people are going to be troubling to reassign
> to new tablespaces are enormous ones, you'd want the transfer to be as
> efficient as reasonably possible.
>
> The main thing this is omitting is "what about wal-logging the move"?

Yes, that's what I was thinking.

> Perhaps we could emit one WAL record showing the source and dest
> RelFileNodes and number of blocks for the copy, and then LSN-stamp
> each copied block with that record's LSN.  However I'm not sure how to
> replay that if the source file isn't there anymore when the replay needs
> to run :-(.  Maybe you have to dump each block into WAL as you copy it.
> That would be kinda ugly ... though in point of fact less of a WAL load
> than writing individual tuples ...

Should I use the WAL-enabled case of  _bt_blwritepage() as a guide here?

Gavin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Next
From: Gavin Sherry
Date:
Subject: Re: [PATCHES] ALTER TABLE ... SET TABLESPACE