Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
От | Gavin Sherry |
---|---|
Тема | Re: [PATCHES] ALTER TABLE ... SET TABLESPACE |
Дата | |
Msg-id | Pine.LNX.4.58.0406211319220.26268@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: [PATCHES] ALTER TABLE ... SET TABLESPACE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
|
Список | 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 по дате отправления: