>>>>> On 22 May 2006 03:00:55 -0400, Greg Stark <gsstark@mit.edu> said:
> 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.
Yeah.
That was what I hoped, although it was too optimistic.
>> *** 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?
These two "tablespace not empty" results both came from NFS mounts.
(I should have said that explicitly, sorry.)
So, this means the REMOVE RPC sometimes may overtake other RPCs?
Hmm...
FWIW, no option was specified to mount tmpfs.
>> *** ./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?
No.
Because this is a result from tmpfs, and before this failure,
"make check" passed almost 100 times on this tmpfs.
It seems your explanation can describe what's happening in the NFS case,
Thanks!
--
soda
