I understand that it is undesireable to run a database over NFS. However, due to the shortage of local space on my machine, I had to utilize NFS space on another machine as an additional tablespace. The tables got created fine on the NFSed tablespace. Now that I have some more local space on my machine, I wanted to move the tables from the remove tablespace "ts2" to the default tablespace "pg_default". Postgres seems to not like that a whole lot.
The "alter table" works fine for some tables and then it hangs. The relative location of this hung-status changes from one run to the next. The hung request does not want to cancel or die (via kill without any flags) either. It also consumes a good chunk of the CPU cycles. It feels like there is some sort of a spin lock which got stuck. Additional "alter table" requests in separate sessions continue to work fine. There are no NFS errors logged. The tables are a couple hundred megabytes each. My NFSed directory is mounted "rw,tcp,hard,intr,rsize=8192,wsize=8192". And I am running Postgres 8.1 on a dual processor 64-bit AMD.
Are there certain dos and don'ts of NFS file space usage in postgres? Is there a way of killing the stuck clients?
Thanks. PS: From the looks of the data files belonging to the table, it seems that the entire data had been copied and then postgres got stuck.
