Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

2008-10-07 Thread Guillaume Lelarge
Heikki Linnakangas a écrit : > Tom Lane wrote: >> Heikki Linnakangas <[EMAIL PROTECTED]> 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 relfile

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

2008-10-07 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> 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 permissio

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

2008-10-06 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> 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 permissio

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

2008-10-06 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> 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

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

2008-10-06 Thread Heikki Linnakangas
Guillaume Lelarge wrote: Tom Lane a écrit : Heikki Linnakangas <[EMAIL PROTECTED]> 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 TAB

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

2008-10-06 Thread Guillaume Lelarge
Tom Lane a écrit : > Heikki Linnakangas <[EMAIL PROTECTED]> 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 as

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

2008-10-06 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> 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 us

Re: [HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

2008-10-06 Thread Heikki Linnakangas
Guillaume Lelarge wrote: db1=# alter table t1 set tablespace ts1; ALTER TABLE /opt/postgresql-8.3/data/base/74472/74475 db1=# \! ls -l /home/guillaume/ts1/74472/74475 -rw--- 1 guillaume guillaume 8192 Oct 6 11:00 /home/guillaume/ts1/74472/74475 My table moved to my own tablespace. db1=# \!

[HACKERS] Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement

2008-10-06 Thread Guillaume Lelarge
Hi, I just found a weird behaviour with this statement. Here is a complete log of my session with a 8.3(.4) server: [EMAIL PROTECTED] mkdir /home/guillaume/ts1 [EMAIL PROTECTED] createdb db1 [EMAIL PROTECTED] LANG=C psql db1 Welcome to psql 8.3.4, the PostgreSQL interactive terminal. Type: \cop