Re: "make check" fails over NFS or tmpfs

From: Greg Stark <gsstark(at)mit(dot)edu>
To: SODA Noriyuki <soda(at)sra(dot)co(dot)jp>
Cc: pgsql-general(at)postgresql(dot)org, takuya(at)soum(dot)co(dot)jp
Subject: Re: "make check" fails over NFS or tmpfs
Date: 2006-05-22 07:00:55
Message-ID: 87ac9amtlk.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


SODA Noriyuki <soda(at)sra(dot)co(dot)jp> 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rafael Martinez, Guerrero 2006-05-22 07:17:29 Re: "make check" fails over NFS or tmpfs
Previous Message Luckys 2006-05-22 06:03:20 Re: PostgreSQL internals. Help needed