SODA Noriyuki <soda@xxxxxxxxx> writes: > NFS server: > OS version: Fedora Core 3 Linux > "async" is specified in /etc/exports, thus the server violates > the NFS protocol, and replys to requests before it stores > changes to its disk. The reason the protocol is speced the way it is is because it's the only way to gaurantee the semantics match the traditional unix semantics of a local filesystem. That said I would have expected a good NFS server to still live up to everything important as long as the server doesn't actually crash or get shut down at any point. I certainly would have expected tmpfs to live up to the traditional unix filesystem semantics. > *** 35,37 **** > --- 35,38 ---- > NOTICE: drop cascades to table testschema.foo > -- Should succeed > DROP TABLESPACE testspace; > + ERROR: tablespace "testspace" is not empty This one looks like the unlink is returning before it completes and then subsequent operations (perhaps only if they come from other processes?) are allowed to see the old filesystem state. That really ought not every happen even with async and certainly not in tmpfs. This might bear some further testing. Can you send the exact commands you used to set up the tmpfs filesystem? Also, it might be worth checking if Fedora Core 3 has any relevant known bugs. > ====================================================================== > > *** ./expected/sanity_check.out Fri Sep 9 05:07:42 2005 > --- ./results/sanity_check.out Fri May 19 16:31:37 2006 > *************** > *** 17,22 **** > --- 17,24 ---- > circle_tbl | t > fast_emp4000 | t > func_index_heap | t > + gcircle_tbl | t > + gpolygon_tbl | t > hash_f8_heap | t > hash_i4_heap | t > hash_name_heap | t This seems pretty mystifying. Perhaps it's leftover stuff from the tablespace that failed to get dropped? -- greg
