Re: [PATCHES] ALTER TABLE ... SET TABLESPACE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Date: 2004-06-21 02:30:29
Message-ID: 12077.1087785029@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Gavin Sherry <swm(at)linuxworld(dot)com(dot)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"?
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 ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Sherry 2004-06-21 03:20:09 Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Previous Message Bruce Momjian 2004-06-21 02:12:27 Re: nested xacts and phantom Xids

Browse pgsql-patches by date

  From Date Subject
Next Message Gavin Sherry 2004-06-21 03:20:09 Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
Previous Message Bruce Momjian 2004-06-21 02:12:27 Re: nested xacts and phantom Xids