Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement
От | Heikki Linnakangas |
---|---|
Тема | Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement |
Дата | |
Msg-id | 48EB44F6.8060009@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE
... statement
|
Список | pgsql-hackers |
Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> Yeah, seems like we need to allocate a new relfilenode in the new >> tablespace. > > I looked into tablecmds.c and verified that ATExecSetTableSpace doesn't > worry about selecting a new relfilenode. I'm also noticing a number of > permissions-type checks that seem like they'd better be done in > ATPrepSetTableSpace, because we don't go through ATExecSetTableSpace > if the table requires rewriting for other reasons. The same tests are performed in the rewriting code path in ATRewriteTables() and in heap_create_with_catalog(). I fixed the relfilenode allocation in 8.1-HEAD. Doesn't seem worth fixing in 8.0, because GetNewRelFileNode() didn't exist before 8.1, so we couldn't check for collisions anyway. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: