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
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 |
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 |