Thread: alter table set tablespace over nfs getting stuck

Good Day:

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.

s anwar <sanwar@gmail.com> writes:
> My NFSed directory is mounted
> "rw,tcp,hard,intr,rsize=8192,wsize=8192".

ISTR some discussion recently about INTR not being a good idea on NFS
mounts.  Does it work any better without that?  You might also try
sticking to the default rsize/wsize, whatever it happens to be.

            regards, tom lane

Thank you. That is working much better.

Regards.