Re: [PATCHES] ALTER TABLE ... SET TABLESPACE
От | Gavin Sherry |
---|---|
Тема | Re: [PATCHES] ALTER TABLE ... SET TABLESPACE |
Дата | |
Msg-id | Pine.LNX.4.58.0406211426170.26738@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: [PATCHES] ALTER TABLE ... SET TABLESPACE (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Список | pgsql-hackers |
On Mon, 21 Jun 2004, Tom Lane wrote: > Gavin Sherry <swm@linuxworld.com.au> writes: > > On Sun, 20 Jun 2004, Tom Lane wrote: > >> 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? > > Yeah, actually that is a very good parallel. If PITR archiving isn't > turned on, you don't have to dump pages into WAL; you can substitute > an fsync before commit, instead. And if it's a temp table then you > don't have to do either. (Not sure anyone would ever do SET TABLESPACE > on a temp table, but might as well get it right.) > > The xlog action here of copying a page image is currently > btree-specific, but maybe we should move it to a more widely visible > place, such as heapam.c. I don't see any value in having identical > xlog recovery actions in several different modules. I was just thinking that. I imagine that this would be useful for WAL logging of createdb() when that functionality gets implemented. We might also be able to use it as a speed up for cluster() (some time in the future). That is, we could form a complete page in memory in relation_rebuild() and then write it out directly. Gavin
В списке pgsql-hackers по дате отправления: