Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement |
| Дата | |
| Msg-id | 48EA06AA.4030302@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement (Guillaume Lelarge <guillaume@lelarge.info>) |
| Ответы |
Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement
|
| Список | pgsql-hackers |
Guillaume Lelarge wrote: > Tom Lane a écrit : >> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >>> The trivial fix is to just force a checkpoint in ALTER TABLE SET >>> TABLESPACE. Can we do better than that? Perhaps only force a checkpoint >>> when we find that the file already exists. >> If ALTER TABLE SET TABLESPACE is assuming that it can always use the >> same relfilenode number in the new space as in the old, it's just plain >> broken. We need to fix that assumption. > > Do you mean the backend should change the relfilenode number whenever we > use the ALTER TABLE SET TABLESPACE ? I can't think of a way to get twice > the same relfilenode. > > Perhaps a better question would be : how the next relfilenode is computed? 1. Get the next OID from the counter. 2. Check if a file with that name exists. If it does, goto 1. Yeah, seems like we need to allocate a new relfilenode in the new tablespace. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: